🗲БИБЛИЯ QA v. 2.5🗲
Что это за проект?
“Библия QA” - это копилка полезностей объемом 370+ страниц:
Дисклеймер:
----- F.A.Q. для новичков ----- 9
Ответы на самые популярные вопросы новичков в чатах 9
Качества и навыки, которыми нужно обладать тестировщику? 10
Что должен знать junior? А что спросят на собеседовании? 11
Как вообще происходит процесс найма? 15
Как проходить собеседование? 15
Я получил оффер, что будет в первые рабочие дни? 17
Ошибки в работе у начинающих тестировщиков? 18
Как правильно задавать вопросы? 18
О процессах и что делать единственному тестировщику в команде 19
----- Полезные ссылки ----- 21
Список полезных ресурсов на разных платформах 21
Список ресурсов по инструментам тестировщика 24
----- HR-вопросы на собеседовании ----- 30
Вопросы с реальных собеседований с этапа HR 30
HR: Что делать, если разработчик утверждает, что найденный дефект таковым не является? 30
HR: Пришел баг из продакшена, что делаем? 31
HR: Кто виноват в багах, найденных в процессе регресса? 31
HR: Как решать конфликты в удаленной команде? 31
HR: Как понять, что тестировщик хорошо сделал свою работу? 31
----- Теоретическая часть ----- 33
Обеспечение качества (Quality Assurance - QA) 33
Контроль качества (Quality Control - QC) 34
Почему требуется тестирование ПО? 35
Качество ПО (Software Quality) 35
Верификация и валидация (Verification and Validation) 37
Серьезность и приоритет Дефекта (Severity & Priority) 45
Подход к тестированию (Test Approach) 47
Тестовое покрытие (Test Coverage) 48
Импакт анализ (анализ влияния, Impact Analysis)? 49
Анализ первопричин (RCA - Root Cause Analysis) 50
Модель зрелости тестирования (TMM - Test Maturity Model) 53
Тестирование со сдвигом влево (Shift left testing) 54
Независимое тестирование (Independent testing) 55
Тестирование как сервис (TaaS – testing as a Service) 56
Альфа- и бета- тестирование (Alpha Testing and Beta Testing) 56
Как протестировать продукт без требований? 59
Тестовая среда и тестовый стенд (Test Environment/Test Bed) 62
Тестовые данные (Test Data) 63
Политика отсутствия багов (ZBP - Zero Bug Policy) 63
Виды/типы/уровни тестирования 68
Типы/методы тестирования (White/Black/Grey Box) 68
Тестирование черного ящика (Black Box Testing) 68
Тестирование белого ящика (White Box Testing) 72
Тестирование серого ящика (Grey Box Testing) 74
Статическое и динамическое тестирование (Static Testing, Dynamic Testing) 74
Пирамида / уровни тестирования (Test Pyramid / Testing Levels) 75
Модульное/юнит/компонентное тестирование (Module/Unit/Component testing) 76
Интеграционное тестирование (Integration testing) 78
Системное тестирование (System Testing) 81
Приемочное тестирование (AT – Acceptance testing) 82
Основные виды тестирования ПО 83
Функциональное тестирование (Functional/Behavioral testing) 86
Нефункциональное тестирование (Non-Functional testing) 87
Тестирование производительности (Performance testing) 89
Тестирование емкости (Capacity testing) 94
Нагрузочное тестирование (Load testing) 95
Стрессовое тестирование (Stress testing) 98
Тестирование масштабируемости (Scalability testing) 99
Объемное тестирование (Volume testing) 100
Тестирование выносливости/стабильности (Endurance/Soak/Stability testing) 102
Тестирование устойчивости (Resilience testing) 102
Тестирование надежности (Reliability Testing) 103
Тестирование на отказ и восстановление (Failover and Recovery testing) 104
Эталонное и базовое тестирование (Benchmark and Baseline Testing) 104
Тестирование хранилища (Storage testing) 105
Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing) 106
Тестирование сервиса (Service Testing) 106
Тестирование безопасности (Security and Access Control testing) 107
Оценка уязвимости/защищенности (Vulnerability Assessment) 112
Фаззинг-тестирование (Fuzz testing) 118
Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тестирования? 119
Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing) 119
Конфигурационное тестирование (Configuration testing) 121
Тестирование на соответствие (Conformance/Compliance testing) 123
Тестирование удобства пользования (Usability testing) 123
Тестирование доступности (Accessibility testing) 125
Инсталляционное тестирование (Installation Testing) 126
Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internationalization testing) 127
Исследовательское тестирование (Exploratory testing) 129
Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing) 131
Тестирование поддержки (Maintenance testing) 133
Регрессионные виды тестирования (Regression testing) 135
Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing) 140
Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing) 140
Тестирование API (API - Application Programming Interface) 142
A/B тестирование (A/B Testing) 146
Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT – Non Destructive testing) 149
Выборочное/хаотическое тестирование (Random/monkey testing) 149
Тестирование рабочего процесса/воркфлоу (Workflow testing) 151
Тестирование документации (Documentation testing) 152
Мутационное тестирование (Mutation testing) 154
Разница тестирования ПО и железа (Software Vs. Hardware testing) 155
Параллельное тестирование (Parallel testing) 157
Тестирование качества данных (Data Quality Testing) 158
Подкожный тест (Subcutaneous test) 159
Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques) 161
Dynamic -> Experience based 189
Тестовая документация/артефакты (Test Deliverables/test artifacts) 191
Виды тестовой документации 191
Политика качества и политика тестирования (Quality policy and Test policy) 193
Стратегия тестирования (Test strategy) 194
План тестирования (Test plan) 195
Тестовый сценарий (Test scenario) 197
Баг-репорт (Defect/bug report) 200
Пользовательские истории (User stories) 210
Критерии приемки (Acceptance Criteria) 212
Базис тестирования (Test basis) 215
Матрица трассируемости (RTM - Requirement Traceability Matrix) 216
Метрики тестирования (Software Test Metrics) 217
Тестовый оракул (Test oracle) 219
Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle) 221
Жизненный цикл тестирования ПО (STLC – Software Testing Lifecycle) 222
Подходы к разработке/тестированию (... - driven development/testing) 241
(Не обновлялось) Тестирование в разных сферах/областях (testing different domains) 243
Тестирование банковского ПО 249
Тестирование электронной коммерции (eCommerce) 249
Тестирование платежного шлюза (Payment Gateway) 252
Тестирование систем розничной торговли (POS - Point Of Sale) 253
Тестирование в сфере страхования (Insurance) 255
Тестирование в сфере телекоммуникаций (Telecom) 258
Тестирование протокола: L2 и L3 OSI 259
Тестирование интернета вещей (IoT - Internet of Things) 261
Облачное тестирование (Cloud testing) 263
Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture) 265
Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning) 268
Тестирование качества видеосвязи WebRTC-based сервиса видеоконференций 269
Тестирование VR программного обеспечения 271
Тестирование микросервисной архитектуры 271
Тестирование платформы электронного обучения 271
Тестирование игр (Gamedev) 271
Тестирование блокчейна (Blockchain) 273
Тестирование банкомата (ATM) 273
Особенности в тестировании мобильных приложений 274
Архитектура Android Application 282
Архитектура iOS Application 298
iOS/Android Developer Settings 304
Основные различия iOS и Android 307
Последнее обновление Android/iOS, что нового? 308
Основные проверки при тестировании мобильного приложения 308
Каким образом тестировщик получает приложение на тест? 312
Push-уведомления: принципы работы и способы тестирования 313
Как проверить использование процессора на мобильных устройствах? 316
Как успешно зарелизить продукт в App Store и Google Play 316
Android Debug Bridge (ADB) 318
Тестирование требований к мобильным приложениям 318
Разработка и тестирование мобильных дип линков (mobile deep links) 318
Тестирование сохраненных поисков 318
Тестирование покупок в приложениях 318
(Не обновлялось) Сети и около них 320
Клиент - серверная архитектура? 320
Endpoint, ресурс, URI, URL, URN 328
Веб-сервис (WS - Web service) 330
Сокет/веб-сокет (socket/web-socket) 331
Какие еще бывают протоколы? 334
Куки (cookies) и их тестирование 334
Статические и динамические веб-сайты 337
Отличие stateless и stateful 337
Почему важно тестировать в разных браузерах? 340
Адаптивный и отзывчивый веб-дизайн (Adaptive vs. Responsive) 341
Как сервер узнает, с какого типа устройства/браузера/ОС/языка вы открываете веб-сайт? (Например, для Adaptive design) 342
Какие заголовки (headers, хедеры) важны тестировщику? 342
Авторизация и аутентификация 342
Кэш и зачем его очищать при тестировании 347
Брокер сообщений (Message broker) 347
Как работает браузер (коротко) 348
Как работает сотовая связь 349
Как работает подключение к Wi-Fi 350
(Не обновлялось) Базы данных 350
Может ли у ПО быть сразу несколько баз данных? 352
Что такое нормальные формы? 353
Понятие хранимой процедуры? 354
Что такое индексы? (Indexes) 355
Что вы знаете о требованиях ACID? 355
Что такое “федеративные таблицы” в Mysql? 355
Так как тестировать базы данных? 355
Какие шаги выполняет тестировщик при тестировании хранимых процедур? 355
Как бы вы узнали для тестирования базы данных, сработал триггер или нет? 355
Как тестировать загрузку данных при тестировании базы данных? 355
Подробнее о джойнах? (Join) 360
----- (Не обновлялось) Практическая часть ----- 365
Дана форма для регистрации. Протестируйте. 365
Определение серьезности и приоритета 368
Определение граничных значений и классов эквивалентности 369
Тестирование чашки для кофе 374
Вот тебе комп и работающий сайт. Сделай мне 401-ю ошибку 376
Оценить время на тестирование лендинга 376
Хочу войти в айти (в разработку) через тестирование, хороший план?
Это работало несколько лет назад, потому что тогда к новичкам-тестировщикам могло вообще не быть никаких требований кроме здравомыслия, но общий технический уровень в индустрии сильно вырос, а после эпидемии и агрессивной рекламы работы в IT со стороны “обучающих” компаний появились тысячи выпускников курсов по тестированию, так что этого “легкого пути вкатиться в айтишечку” уже нет и не будет и не нужно вестись на рекламу этих инфоцыган. Конкурс на одно место на удаленку может доходить до нескольких сотен человек. Конечно, в разработке тоже конкуренции поприбавилось, но если вы нацелены стать программистом, то никакие вхождения через другие специальности не имеют ни малейшего смысла - тестирование и разработка - разные профессии и опыт работы джуниор тестировщиком вам практически ничем не пригодится, вы лишь потратите время на подготовку к собеседованиям (а требования теперь весьма высокие), а потом еще на переобучение непосредственно той специальности, куда хотели изначально, т.к. опыт по сути не релевантен и спрашивать будут с нуля. Кейс перехода из тестирования в разработку (впрочем как и наоборот) встречается только у опытных специалистов и по совсем другим причинам.
Если же говорить просто о желании работать где-нибудь, лишь бы в сфере информационных технологий, то тяп-ляп быстренько прочитать пару книжек и сразу устроиться чтобы получать много денег тут не прокатит. Стоит изучить огромный перечень специальностей и понять для себя, что из этого ближе и развиваться сразу в нужном направлении, как бы невозможно это ни казалось.
Доп. материал:
Хочу зарабатывать много денег, мне сюда?
Первые зарплаты будут небольшими (особенно учитывая конкурс на места), а подняться выше по карьерной лестнице без искреннего интереса не получится, тестирование - слишком обширная область знаний. Без внутренней мотивации к ежедневному самообучению не получится зарабатывать больше чем в любой другой профессии на старте. Так что сферу деятельности стоит менять только если вы всю жизнь чувствовали, что занимаетесь не тем, а тут ёкнуло и хочется взахлеб осваивать именно тестирование. Но даже в этих случаях нужно понимать, что тестирование - не рекордсмен по зарплатам. Далеко не всем компаниям требуются эксперты тестировщики, как это может быть в случае с разработчиками. Именно по этой причине существует отток уже проработавших какое-то время в тестировании специалистов, в другие направления: менеджмент, чистая автоматизация, разработка. Фактически они просто не смогли найти дальнейшие пути развития своих навыков или спрос на свои навыки в текущем рынке при желаемых условиях. Соответственно и зарплаты здесь в среднем ниже, чем на многих специальностях в IT.
Доп. материал:
Мне 30/40/50, кому-то нужен такой старик в команде?
Хорошая новость в том, что на возраст в IT чаще не смотрят. Безусловно, есть и молодые команды, куда возрастной коллега не впишется. Но в это же время существуют множество других команд, где возраст нового коллеги не имеет значения. Другой вопрос в том, готовы ли вы подчиняться 25-летнему сеньору и поспевать в обучении за вчерашними студентами. Можно поискать по истории сообщений в QA-сообществах телеграма, там этот вопрос неоднократно поднимался и там же есть истории смены сферы деятельности и успешного трудоустройства и в 40+ и в 50+.
Доп. материал:
Хочу работать удаленно джуном, это возможно?
Плохая новость в том, что шансы устроиться на удаленку специалисту без опыта сами по себе довольно низкие - высокая конкуренция, к тому же компании охотнее берут начинающих в офис (так эффективнее обучать). Поэтому попробовать, конечно, стоит, но рассчитывать на это особо не нужно. Да и начинающему действительно продуктивнее находиться в офисе вместе со всей командой, в гуще событий.
У меня нет высшего образования или я гуманитарий, всё пропало?
Зависит от требований нанимателя, но в большинстве случаев само наличие диплома никому не интересно, т.к. это ещё ни о чем не говорит (разве что есть какие-то достижения за время учёбы). Обычно такое требование можно увидеть только в вакансиях крупных компаний, да и то на деле оно чаще оказывается не обязательным. Не-техническая же специализация может оказаться вполне полезной, потому как бухгалтеров-экономистов охотно возьмут тестировать финтех, медиков соответственно медицинское ПО и т.д., а диплом переводчика вообще открывает некоторые двери автоматически.
Я всю жизнь работал %название должности%, это может как-то пригодиться в тестировании?
По аналогии со сказанным выше, потенциально почти любой опыт можно как-то использовать в тестировании. Если говорить о максимально близкой работе, с которой чаще всего и растут сюда, то это техническая поддержка, реже эникеи и начинающие “сисадмины”.
Доп. материал:
У меня старый компьютер, придется купить макбук про для работы?
В офисе или на удаленке в приличной компании вас всем обеспечит работодатель. Если же вы сами по себе или просто хотите узнать приемлемую конфигурацию, то для мануального тестировщика ресурсы рабочей машины и операционная система глобального значения не имеют, для комфортной работы ориентируйтесь на последнюю версию ОС, CPU 4 ядра/4 потока с поддержкой виртуализации + SSD + 8Gb RAM - этого хватит для любых задач. Если смотреть на перспективу, то для контейнеров, эмуляторов и всего такого потребуется больше потоков и от 16Gb оперативки. При использовании эмулятора вам пригодится поддержка аппаратного ускорения видео у APU или дискретной видеокарты.
Доп. материал:
Про soft-skills:
Конкретного ответа на этот вопрос нет, всё зависит от конкретной компании и вакансии. Но вот пара ссылок на карты знаний для тестировщиков, можете на просторах найти и другие.
Некоторые компании подробно расписывают на своих порталах ожидания от каждой стадии развития сотрудника, по этой же теме много видео на Youtube (раз, два, три, четыре, …). Еще один ориентир – просто открыть и почитать вакансии, выписывая повторяющиеся пункты.
Если же попытаться выделить самые частые вопросы на собеседованиях, то получится примерно следующее:
*Просто для цельной картины, если говорить про уровень middle, то работодателей теория уже не так интересует, если только это не крупная галера с высоким конкурсом (вопросы в таком случае будут +- те же, что и для junior, просто копнут глубже). Мидл - самостоятельная в решении рядовых задач боевая единица. Такой специалист уже имеет опыт в задачах, инструментах, видел какие-то процессы и уже хотя бы примерно может давать оценку времени на выполнение задачи. Соответственно и спрашивать будут больше по таким кейсам и по предыдущему опыту работы. Senior это уже про серьезный опыт, а также: автоматизация, CI/CD и место автоматизации в нём, менеджмент процессов и их построение, планирование, метрики, ROI, знание стандартов, опыт в тест планах и стратегиях, декомпозиция и распределение задач, оценка времени и т.п..
Помимо вышеперечисленного нужно помнить об английском языке. Он нужен для чтения документации и актуальных статей, просмотра вебинаров, поиска ответов на вопросы, т.к. в русскоязычном сегменте информации в разы меньше и пока ее переведут она уже устаревает. В РБ и Украине гораздо чаще чем в РФ язык нужен для ведения проектной документации и общения с иностранными коллегами (не надейтесь особо на переводчики и авто субтитры, всё это еще далеко от совершенства). Конечно, компании работающие на внутренние рынки могут не требовать знание языка, но тут, опять же, остается открытым вопрос личного развития. Если же в вакансии указан необходимый уровень владения языком, то будьте готовы к тому, что как минимум попросят ответить на какой-нибудь простенький житейский или HR-вопрос на английском. В отдельных случаях, где явно указана необходимость разговорного уровня, все собеседование вполне может пройти на английском.
Доп. материал:
Начать нужно с простого ознакомления с тестированием и самый частый совет для этого - книга Романа Савина “Тестирование дот ком”, которая не учебник, а скорее худ. лит. на 1-2 вечера, и местами спорная, но простыми словами расскажет о тестировании. После ознакомления я бы посоветовал выбрать по отзывам в коммьюнити хороший базовый онлайн-курс и пройти его, либо по возможности пойти на офлайн-курсы местной компании с возможностью последующего трудоустройства - это вообще лучший вариант. Если нет возможности, то хорошим выбором будет бесплатная книга Святослава Куликова “Тестирование программного обеспечения. Базовый курс” + бесплатный курс в дополнение к ней и далее уже имея общее представление и понимая азы равномерно восполнять пробелы, подготавливаясь к собеседованиям.
Тестирование – очень широкая область и, хотя базовая теория и не сильно сложная, ее довольно много. В отрыве от практике она плохо усваивается и быстро забывается, вы начинаете путаться. Нужно пытаться как можно быстрее найти применение своим навыкам. Начать стоит с тестирования приложений и сайтов, которыми нравится пользоваться или любых других, а также классики типа тестирования форм, тренировочных сайтов с дефектами специально для тестировщиков и т.п. Отдельно советую действительно вдумываться во все практические примеры до полного понимания и способности решать аналогичные кейсы самостоятельно, просто за факт прочтения деньги платить не будут. Не стоит забывать и о софт скилах (учитесь адекватно общаться с людьми в профильных чатах) и базовой грамотности (смолоду тренируйтесь в составлении тестовых артефактов).
По мере роста компетенций как можно раньше стоит начать проходить собеседования и пытаться устроиться на любую стажировку, вообще любой вариант, где вы сможете применять знания и указать этот опыт в резюме, т.к. без опыта сейчас найти работу очень трудно. Если нет никаких оффлайн вариантов, как было у меня, можете регистрироваться на краудтестинговых платформах (но зачастую это гиблое дело + многие работодатели игнорируют такой опыт), искать в тг-каналах возможности протестировать какие-то проекты за бесплатно (иногда там ищут волонтеров за опыт) либо придумать такой тестовый проект себе самому - снова взяться тестировать какое-либо приложение или сайт, но теперь делать это близко к тому, будто это ваша реальная работа. То есть чтобы было что потом рассказать и показать результаты (тест-кейсы, баг-репорты и т.п.). Багов хватает в любом популярном приложении/сайте, стоит только поискать, хотя баг-репорты и не главное. Главное показать понимание что и как тестировать.
Когда вы устроитесь на свою первую работу, спустя некоторые время сможете начать готовиться к дальнейшему развитию и выбору направления, ведь никто не заставляет всю жизнь быть ручным тестировщиком. Вы можете сосредоточиться на mobile/web/desktop платформе, профессионально развиваться в менеджеры или автоматизацию, готовиться к узкой специализации — безопасности или performance и т. д., либо сфокусироваться на подготовке по перспективным направлениям:
Помимо прочего, специалисту, планирующему развиваться профессионально, желательно как можно раньше начать сначала посещать релевантные митапы и конференции, а когда-нибудь и начать выступать в роли докладчика. Также не лишними будут различные сертификации (хотя бы тот же ISTQB разных уровней) если работодатель оплачивает банкет, но вообще istqb если где и смотрят, то на западе и обычно не более чем как небольшой бонус.
Доп. материал:
Кратко о базовых рекомендациях.
Размер резюме стажера или джуниора – ровно 1 страница (имеется в виду вариант в файле, а не на площадках). Вариант минимум: PDF + расшаренная копия на google-диске. Вариант получше: резюме в веб-версии на github-pages + из варианта минимум.
Язык резюме – русский, если нацелены на компании из РФ с клиентами из РФ (или рекрутерами без знания английского :). В остальных случаях – английский.
Шапку можно оформить без наворотов: Нейтральное фото, по которому вас можно узнать, ФИО, на какую позицию претендуете, актуальные контакты, опционально локация.
Опыт работы (любые практические навыки) идет сразу после шапки. Это самая важная часть резюме. Без лишней воды кратко и емко описывается чем конкретно вы занимались. Общее правило - использовать глаголы совершенного вида (сделал то, там-то; а делал, участвовал - ничего о вас не говорит), а еще лучше в формате «зона ответственности + достижения».
Навыки и технологии. С чем работали, что умеете. Никогда не используйте банальные ключевые навыки «ответственный, целеустремленный, …». Только конкретика. Помните, что HR часто ищут по ключевым словам, а вы не должны раздувать ваше резюме всяким мусором. Технологии, инструменты – хороший выбор. Но будьте готовы, что вас по ним детально будут спрашивать в первую очередь. Не забудьте упомянуть знание иностранных языков. Сориентироваться поможет, например, бесплатный тест EFSET с сертификатом или андроид-приложение EnglishScore: Free British Council English Test.
Образование и самообразование. Университет, курсы, книги и т.п. Кратко и по существу.
Раздел «О себе» можно включить, если есть что важного и интересного написать, опять же, коротко и если есть чем выделиться.
При отклике на вакансию встает вопрос о сопроводительном письме. Чаще всего их всё-таки читают, но не надо их писать просто для галочки, это сразу бросается в глаза и идет в минус. Тут лучше поступать аналогично с разделом “О себе” - пишите только если это действительно нужно, т.е. вы ознакомились с информацией о компании, вам есть чем выделиться среди других кандидатов и вы точно можете описать какие ваши навыки и как пригодятся бизнесу нанимателя. Для компании найм джуна это очень дорого и хорошо если кандидат начнет окупаться после полугода в штате, поэтому разговор с работодателем на понятном ему языке доход/расход может вас выделить из серой массы.
Вообще на тему составления резюме в IT есть миллион статей (пример) и видео на youtube, да и не стоит исключать фактор личных пристрастий нанимателя, так что следует просто следовать базовым рекомендациям и периодически корректировать в зависимости от результатов, а если всё плохо, то можно скинуть итоговый вариант на оценку в коммьюнити.
Насчет самих откликов, тут на мой взгляд уместна аналогия с холодными звонками, т.е. не нужно на начальном этапе выбирать место работы так, будто у вас лишь один шанс и вы собираетесь в ней состариться. Вообще слать резюме стоит не только откликаясь на вакансии. Есть мнение, что когда компания выкинула вакансию на работные сайты, это уже тупик (т.к. не нашли кандидата по своим каналам). Шлите на почты IT-компаний, HR-ов, расширяйте сеть контактов в linkedin и т.п.. Слышал, что активные джуны рассылали по несколько сотен писем в неделю. Стоит ли говорить, что они быстро нашли свою первую работу?
Дополнительно я бы посоветовал ознакомиться с разными типами компаний. Работа в инхаус и аутсорс заметно отличается и помимо просто понимания, куда бы вам больше хотелось, преимуществом будет знать, как подогнать резюме и отклик под конкретный тип.
Доп. материал:
Все зависит от компании и в меньшей степени от уровня позиции. В среднем это выглядит так:
В очень больших компаниях с потоковым наймом бывает и по 6-7 этапов интервью, в мелких местных же всё может обойтись одной встречей с беседой за кофе.
Прежде всего, конечно, на него не нужно опаздывать. В случае оффлайна стоит прийти немного заранее, оглядеться, привыкнуть к атмосфере и настроиться на нужный лад. Требований по дресс-коду обычно нет, стоит просто быть опрятным и ориентироваться на “среднюю температуру по больнице” (району), т.е. не идти в Москва-сити в пляжных шортах и сланцах, так же как и не идти в офис на берегу моря в костюме-тройке, всё остальное приемлемо.
В случае онлайна так же необходимо быть на связи уже за 5-10 минут до назначенного времени, поздороваться в чате и сообщить что вы онлайн, устройства должны быть заряжены, интернет стабилен, микрофон и звук настроены и проверены. Приятное впечатление оставят хороший свет и отсутствие постороннего шума. Внешний вид особого значения не имеет, но сидеть с голым торсом и хлебать борщ не стоит (помните про опрятность и здравый смысл). На фон за вами большинству всё равно, хотя сейчас почти везде можно включить размытие.
Главное, что нужно сказать о собеседованиях – их нужно проходить. Регулярно. Это отдельный навык, который утрачивается если не практиковать. Не стоит бояться и относиться к ним как к экзамену, вы и сами это поймете на практике. В знаниях это скорее это как калибровка, нахождение ориентира где вы сейчас находитесь и в какую сторону корректировать курс. Прошли, проанализировали, подкачались – повторяете, пока не будет достигнут приемлемый результат. Некоторые советуют и после устройства на работу периодически ходить на собеседования, чтобы держать этот навык в тонусе и ориентироваться в своей ценности на рынке.
Если вы ищете первую работу, начать ходить на собеседования нужно как можно раньше еще и потому, что никто не задумывается, как долго в реальности может занять процесс поиска работы. Сначала нужно будет выбить себе возможность пройти интервью. Цифры примерно такие: 10 откликов на подходящие вакансии или 100 рассылкой = 1 собес. 10 не заваленных собесов = 1 оффер. Принятие решения компанией может занимать пару недель. В некоторых компаниях этапов может быть штук 7. Средне-оптимистичный сценарий предполагает от 2-3 месяцев с нуля до начала работы, но это в случае наличия вокруг выбора и хорошей подготовки у кандидата (а на этот счет тоже многие заблуждаются). В не идеальном случае процесс займет от полугода (и даже год не редкость).
Основное, что хочется сказать про само собеседование:
Узнай всё что можешь о компании, в которую идешь проходить собеседование.
Не скромничай и не занижай свои навыки. Ты, возможно, 50-й кандидат на этой неделе и еще 100 будет после тебя. Если будешь мяться – про тебя забудут, как только ты закроешь за собой дверь. Здоровая гипербола и немного красок еще никому не мешали. Но никогда не переходи в ложь.
Потренируйтесь в самопрезентации, записывая себя на видео и пересматривая. Обычно первое, что вас спросят – «расскажите о себе». Основная задача HR – проверить адекватность кандидата, в некоторых случаях еще соответствие определенному заказу из целевой команды (от взглядов до хобби, все что угодно). Помните, что собеседуют в компанию в первую очередь человека, а уже потом специалиста. Кто-то сравнивает собеседование со свиданием, где за час вы должны понять, подходите ли вы друг другу. Вопросы на этом этапе в основном стандартные, ответы на них лучше расписать заранее, но не заучивать. Заученный ответ обычно выглядит нелепо, а вот сформулировать свои мысли заранее и понять себя бывает полезно.
Хороший базовый рассказ о себе определит дальнейший ход собеседования, HR будет копать вглубь от заинтересовавших фактов. Кстати, не на все вопросы вы будете знать ответ и это нормально. Одна из задач рекрутера проверить, как вы себя ведете и как отвечаете, когда не знаете ответ или если вопрос максимально глупый. Или вас попробуют заставить сомневаться в заведомо правильном ответе (в этот момент вы вспомните передачу “кто хочет стать миллионером”). Умение адекватно и грамотно отвечать на вопросы и отстаивать свою точку зрения очень важно для тестировщика.
Еще хороший совет - всё, что вы скажете, может и будет использовано против вас. В том смысле, что не говорите лишнего или того, в чем плаваете, иначе очень быстро закопаетесь в новых вопросах.
В конце (хотя бывает и в начале) спрашивает собеседуемый! Помните, что это обоюдный процесс? Они выбирают себе кандидата, но и вы выбираете себе компанию. Немного информации для борьбы со стеснением: для компании найм сотрудника очень затратная затея. В крупных компаниях даже есть бонусы сотрудникам за удачную рекомендацию знакомого в размере тысяч 100 и это в контексте затрат на обычный процесс найма просто копейки. Обе стороны заинтересованы закрыть торги прямо здесь и сейчас, так что не бойтесь задавать вопросы и будьте полноценной второй стороной в этих переговорах.
По поводу спросить – вот безжалостный копипаст типичных вопросов на любом собеседовании (не бойтесь, что если такое начнет спрашивать начинающий специалист, то на это покрутят у виска. Просто умело и ненавязчиво вплетайте самое важное для вас в беседу и все будет ок):
Хотя я бы лучше уточнил про вентиляцию и свет в помещении, где будет рабочее место, ситуация с перерывами/обедами и всё такое более насущное. “Профильные” вопросы работодателю ищите в доп. материалах и выбирайте что нужно знать именно вам.
Можно еще обратить внимание на такие моменты, как:
Собеседование на английском языке практическое такое же*, просто из-за языкового барьера могут возникать трудности. Практикуйтесь! И помните, что вашему собеседнику может быть так же трудно, как и вам.
*- при собеседовании в другую страну следует учитывать культурные особенности (да и законодательство), потому что некоторые ценности и взгляды могут совершенно не очевидным образом быть разными и при этом иметь решающее значение. Здесь нужно целенаправленно читать статьи о найме или релокации в интересующую страну, там упоминаются эти нюансы и особенности.
Как отвечать на вопросы об ожидаемой компенсации труда каждый для себя решает сам, я лишь призываю не демпинговать и помнить, что любой труд должен оплачиваться. Обычно спрашивают 3 цифры: на испытательном сроке, после, через год. Для столиц цифры в $ очень приблизительно такие: 300-500/500-800/800-1300; для регионов: 200-400/300-600/500-800. Разумеется это при соответствующем росте ваших навыков и в этой перспективе вы уже должны были убедить собеседующего за время интервью.
Доп. материал:
Если вас угораздило быть на первой работе единственным тестировщиком, то скорее всего вас познакомят с коллегами и расскажут о продукте (а вы уже сами должны знать о нем всё что возможно узнать заранее).
Вероятно вас просто с ходу бросят на амбразуру искать баги, возможно писать кейсы и попутно будут отвечать на вопросы, а потом уже всё остальное.
В крупных же компаниях обычно есть налаженный процесс онбординга, который начинается с выдачи прав доступа, настройки рабочих учеток и рабочей станции, знакомства с внутренней структурой проекта и компании, ознакомления со стеком технологий и инструментами. К вам прикрепляют ментора и рассказывают к кому и с какими вопросами можно обращаться.
В любом случае каких-то значимых результатов от новичков первое время никто ждать не будет, обычно есть минимум один “золотой” месяц, когда сотрудника сюсюкают как младенчика на второстепенных задачах, пока тот не вольется в работу, так что не накручивайте себя заранее.
Доп. материал:
Доп. материал:
В чатах, коллегам, на форумах, где угодно:
Доп. материал:
Как решать сложные (технические) проблемы?
Начинать знакомство с проектом лучше с интервью. Станьте журналистом. Что из себя представляет структура организации, а именно кто над кем стоит и кто за что отвечает? Где больше всего багов, каким видят тестирование сейчас и какие ожидания в будущем? Оцените зрелость процессов по CMM и TMM, зрелость проекта (новый/старый-зрелый/старые-зрелые где будут глобальные изменения) и команды, определите методологию разработки. Соберите метрики, подбейте статистику, подумайте как на эту статистику можно повлиять. Проведите вводную лекцию команде: что такое QA, как оно может помочь, с какими проблемами обращаться и зачем всё это надо. Далее в зависимости от всего этого выбирайте в доп. материалах или на просторах интернета вебинар/статью о процессах (можно поинтересоваться опытом коллег в коммьюнити или поискать по истории) и сверяясь с целями компании аккуратно приступайте к внедрению оных.
Вообще создавать отдел тестирования нанимают QA Lead, а если вы джун без опыта работы, то либо работодатель не понимает что делает, либо у него есть вполне конкретная “боль”, которую он с помощью тестировщика хочет решить, в таком случае проводить целое расследование не придется - наверняка все объяснят еще на собеседовании.
В нормальной ситуации вы проведете исследовательское тестирование, составите несколько наборов кейсов, задокументируете все текущие баги и в дальнейшем будете заниматься тестированием новых сборок, проверкой исправления найденных дефектов и проведением регрессии. Т.е. если вернуться в плоскость процессов, то нужно будет их обдумать и внедрить хотя бы на ключевые моменты: этап составления требований, этап проверки нового функционала перед вливанием в основной, этап регрессии, этап предоставления отчетности (и в целом все заинтересованные лица всегда должны иметь актуальную информацию о текущем состоянии качества релиза/продукта)
Доп. материал:
Telegram:
Must have! Каналы это: знакомство с коммьюнити, живое общение, уникальный опыт тысяч коллег; богатая история сообщений, где поиском по истории сообщений можно найти все что угодно; в шапке каждого канала закреплено сообщение со своим набором полезностей. Кроме того, некоторые каналы специализируются на мониторинге нового полезного материала с основных порталов, так что можно даже не погружаться с головой в хабр, доу, медиум и т.п., вам отберут все самое полезное. В конце концов, в этих каналах публикуются анонсы грядущих онлайн-мероприятий, чтобы ничего не упустить.
Youtube-каналы:
Web:
Книги и материалы:
Курсы:
Списка и конкретных рекомендаций здесь не будет по понятным причинам. Я лишь посоветую обходить стороной разного рода инфоцыган, реклама которых вылезает из каждого утюга и что обещают трудоустройство по записанным лекциям за конский ценник, думаю тут и без конкретики все поймут о каких компаниях речь.
В телеграме есть чат @qa_courses с обсуждением разнообразных нормальных курсов и отзывами о них, ищите по истории сообщений по хештегам, читайте, выбирайте сами (только держите в уме, что админы и сами авторы некоторых курсов). Также есть таблица с отзывами от Артёма Русова.
По поводу всяких sharewood и т.п. Использование слитых курсов - это личное дело каждого, ситуации в жизни бывают разные. Но имейте в виду, что в IT пиратство крайне не приветствуется, упоминать такие поступки не стоит, а обсуждение в чатах может легко закончиться баном. Кроме того, вся ценность курсов именно в практике и обратной связи от преподавателей.
Мобильные приложения:
Подборка для Android, с iOS дела не имел. Возможно, указанные в списке приложения есть на обеих платформах.
Другие сборники материала и ответов на вопросы:
Словари терминов (в т.ч. элементов интерфейса):
Чек-листы и идеи для тестов:
DevTools:
Тестирование API:
Postman представляет собой мультитул для тестирования API. В нем можно создавать коллекции запросов, проектировать дизайн API и создавать для него моки (заглушки-имитации ответов реального сервера), настраивать мониторинг (периодическая отправка запросов с журналированием), для запросов возможно написание тестов на JS, есть собственный Runner и т.д. Постман хорошо подойдет в простых случаях автоматизации или как инструмент поддержки а анализа: проверка работоспособности endpoint, дебаг тестов, простая передача информации о дефектах (можно сохранить запрос в curl, ответ в json и т.п.). Postman также может работать без графического интерфейса (newman).
Proxy (снифферы трафика):
Charles — инструмент для мониторинга HTTP/HTTPS трафика. Программа работает как прокси-сервер между приложением и сервером этого приложения. Charles записывает и сохраняет все запросы, которые проходят через него и позволяет их редактировать.
Тестирование безопасности:
GIT:
Git - это система контроля версий, которая упрощает работу нескольких человек над одним проектом, помогая разрешать конфликты слияния изменений, следить за историей, откатывать эти изменения и т.п.
Ваш репозиторий может быть локальным и/или находиться в: GitHub, Bitbucket, GitLab
Даже ручному тестировщику пригодятся навыки работы с Git: хранить там портфолио для резюме с подтверждением навыков использования инструментов и написания документации, можно само резюме разместить на github pages, уже на работе иногда будет требоваться самостоятельно сбилдить себе сборку на тест или разобраться, в какой момент (в каком коммите) появился баг или наоборот был пофикшен и т.п. Про автоматизацию, очевидно, даже и говорить не стоит - гит там используется ежедневно.
Все что нужно для работы с GIT
SQL:
Это язык программирования, применяемый для создания, модификации и управления данными в базе данных.
Все что нужно для работы с SQL:
Инструменты тестирования мобильных приложений:
Эмуляторы, симуляторы, фермы устройств:
Работа с логами:
Тестирование производительности:
Mind maps:
TMS:
Полезные расширения для браузера:
Программы для снятия скриншотов и записи видео:
RegExp:
Разное:
Часть из них зададут в любом случае. Список, разумеется, не полный:
Указывать на требования, апеллировать к здравому смыслу, подключать аналитика, чтобы объяснил. Если это поведение не описано в доке, то это баг, либо недоработка. Но недоработка в терминах джиры все равно баг
Проверить ТЗ. Если есть расхождение с ожидаемым результатом – привязываем ссылку на ТЗ.
Если формально это не зафиксировано, но вы чувствуете, что на это стоит обратить внимание – идете к писателю/аналитику/менеджеру, объясняете и в случае согласия это попадает в ТЗ.
Если формально не зафиксировано и менеджер с вами не согласен – дефект закрывается.
Доп. материал:
Доверие между тестировщиками и разработчиками
Воспроизводим, запускаем по пути жизненного цикла дефекта и анализируем причины, как данный дефект прошел в прод: устаревшие кейсы, специфика конкретных устройств или конфигураций которых у тестировщика нет, или это вообще была ситуация срочного релиза и кейсы был но решили выпускать без регрессии и тогда это вопрос к процессам. После исправления дефекта разработчиком проводим повторное тестирование. Добавляем данный дефект в регрессию если его там еще нет. В зависимости от охватываемого функционала и Root Cause этих багов принимается решение о проведении sanity/регрессионного тестирования после подтверждающего.
Начнем с того, что хорошо, что эти баги нашлись сейчас тестированием, а не после релиза пользователями. Дальше надо уже разбираться отдельно с каждым конкретным багом. Какие могут быть причины:
Также не стоит забывать про обычный человеческий фактор и если такие ситуация проявляются не часто - то берите во внимание, анализируйте, проговаривайте с командой, но не делайте поспешных выводов и не принимайте радикальных решений.
Источник: https://t.me/qa_chillout/92
Источник:
Как решать конфликты в удаленной команде
Бытует мнение, что основная задача тестировщиков - сломать продукт, на самом деле тот уже приходит на тестирование с дефектами, одна из задач тестировщика как раз их выявить.
Понять, что тестировщик выполнил свою работу хорошо можно по факту выполнения следующих задач:
Это часть Quality Management - совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и поддержки ПО, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта. Т.е. QA обеспечивает создание правильных процессов для получения в результате качественного продукта. Это также означает создание процессов контроля качества (QC), которые в свою очередь гарантируют, что процессы, установленные QA, соблюдаются. Проще говоря, если тестировщик вступает уже после этапа разработки (не считая, возможно, создания артефактов заранее), то QA участвует в каждом этапе SDLC, начиная еще с составления требований, и занимается не проверкой постфактум уже готового ПО на соответствие требованиям и наличие дефектов, а пытается предотвратить само появление этих дефектов, являясь эдаким “инфлюенсером”, специалистом, влияющим на процессы разработки и улучшающий их качество для обеспечения качества итогового продукта.
Если попытаться перечислить некоторые активности, то получится что-то вроде:
Перечислите типичные возможные обязанности QA?
Источник: Real Time Software QA Interview Questions And Answers
Доп. материал:
Это часть QA - процесс установления стандартов и проверки, что ПО сделано правильно. Цель контроля качества - проверить, соблюдалась ли предписанная модель или нет. Это может быть достигнуто путем проведения аудитов и определения того, следовала ли команда определенной модели для достижения качества. Аудит качества - это оценка процесса на месте для обеспечения его соответствия требованиям. Они выполняются под наблюдением аудитора, который проверяет, соблюдались ли установленные руководящие принципы во время создания продукта. Аудиты предназначены не для проверки качества продукта, а для проверки типа работы, выполняемой при создании продукта. Он оценивает, насколько точно соблюдалась предписанная модель. Есть ли вариации? Если да, то в чем причина вариаций? Целью аудитов является постоянное улучшение качества работы, отныне повышая качество продукции. Инспекция может быть одним из аспектов аудита.Инспекция исследует свойства продукта. Он проверяет, насколько хорошо продукт соответствует требованиям, есть ли какие-либо различия между разработанным и желаемым продуктом. Если да, то будет соответствовать требованиям или нет. Сколько продуктов нагрузки / стресса могут выдержать? Какая неблагоприятная ситуация может привести к сбою? Короче говоря, аудит - это проверка качества процесса, используемого при создании продукта. Инспекция - это проверка того, насколько хорошо продукт соответствует требованиям, предъявляемым заинтересованными сторонами. Качество и контроль практикуются в самых разных отраслях, таких как программное обеспечение, производство, автомобилестроение, розничная торговля и т.д., чтобы гарантировать, что все соблюдают стандартную процедуру и практику. Как и при массовом производстве, любое отклонение от стандартной процедуры может привести к ошибкам, которые могут привести к потере огромного количества денег и времени.
Источник: Testing vs Quality Assurance vs. Quality Control What’s the Difference?
Пара официальных определений:
Это часть QC - процесс проверки того, ведет ли себя спроектированный продукт должным образом в различных условиях. Требования документируются в виде test case. Тестировщик верифицирует и валидирует продукт. Если тестируемое требование к продукту ведет себя так, как ожидалось, test case помечается как пройденный (pass/passed), иначе - как неудачный (fail/failed).
Основная цель тестирования - как можно эффективнее найти дефекты / ошибки. Дефект выявляется тестировщиком для failed scenarios и передается разработчику. После того, как дефект будет исправлен разработчиком, требование проверяется для проверки исправления, и соответствующий test case считается passed. Эти петли обратной связи важны на каждом этапе product delivery lifecycle.
Источник: Testing vs Quality Assurance vs. Quality Control What’s the Difference?
Доп. материал:
Доп. материал:
Формально стандарт ISO 8402-1986 определяет качество как совокупность функций и характеристик продукта или сервиса, которые обладают способностью удовлетворять явные или неявные требования. Иными словами, качество заключается в соответствии требованиям (conformance to requirements) и пригодности к использованию (fitness for use), т.е. характеризуется набором свойств, определяющих, насколько продукт "хорош" с точки зрения заинтересованных сторон, например, заказчик продукта или пользователь. Основная последовательность действий при выборе и оценке критериев качества программного продукта включает:
Доп. материал:
Принцип 1. Тестирование показывает наличие дефектов
Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов больше нет.
Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку.
Принцип 2. Исчерпывающее тестирование невозможно
Для проведения исчерпывающего тестирования придется протестировать все возможные входные значения и все пути выполнения программы, в большинстве случаев число таких вариаций стремится к бесконечности или просто на порядки превосходит отведенное время и бюджет. Вместо попыток «протестировать все» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта. При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками – одна из наиболее важных активностей в любом проекте.
Принцип 3. Раннее тестирование
Тестовые активности должны начинаться как можно раньше в SDLC, а именно когда сформированы требования.
Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить. Дефект, найденный в требованиях, обходится дешевле всего.
Еще одно важное преимущество раннего тестирования – экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.
Принцип 4. Скопление дефектов
Небольшое количество модулей содержит большинство дефектов, обнаруженных на этапе предрелизного тестирования, или же демонстрируют наибольшее количество отказов на этапе эксплуатации.
Многие тестировщики наблюдали такой эффект – дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов – тестировщики фокусируются на известных «проблемных зонах». Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
Принцип 5. Парадокс пестицида
Boris Beizer в своей книге Software Testing Techniques объяснил парадокс пестицида как феномен, согласно которому чем больше вы тестируете ПО, тем более невосприимчивым оно становится к имеющимся тестам, т.е.
Из чего следует, что набор тестов и подходов нужно постоянно пересматривать и улучшать для выявления не найденных ошибок, а также необходимо обновлять тесты после исправления уже найденных дефектов.
Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск – это потенциальная проблема. У риска есть вероятность (likelihood) – она всегда выше 0 и ниже 100% – и есть влияние (impact) – те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние.
То же можно сказать и о мире ПО: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьируется. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО – люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи – на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.
Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей.
Иначе говоря, верификация не равна валидации.
Доп. материал:
Верификация - это проверки, выполняемые в процессе разработки ПО для ответа на вопрос: “правильно ли мы разрабатываем продукт?”. Это в т.ч. включает проверку документации: requirements specification, design documents, database table design, ER diagrams, test cases, traceability matrix и т.д. Верификация гарантирует, что ПО разрабатывается в соответствии со стандартами и процессами организации, полагаясь на reviews и статические методы тестирования (т.е. без запуска ПО, но, например, с unit/integration tests). Верификация является превентивным подходом (Preventative approach).
Этап верификации | Действующие лица | Описание | На выходе |
Review бизнес / функциональных требований | Команда разработки / клиент для бизнес-требований | Это необходимый шаг не только для того, чтобы убедиться, что требования собраны и / или корректны, но и для того, чтобы убедиться, выполнимы ли они | Завершенные требования, которые готовы к использованию на следующем этапе - дизайне |
Review дизайна | Команда разработки | После создания дизайна команда разработчиков тщательно его просматривает, чтобы убедиться, что функциональные требования могут быть выполнены с помощью предложенного дизайна | Дизайн готов к имплементации |
Прохождение кода (Code Walkthrough) | Отдельный разработчик | Написанный код проверяется на наличие синтаксических ошибок. Это более обыденно и выполняется индивидуальным разработчиком на основе кода, разработанного им самим | Код готов к unit testing |
Проверка кода (Code Inspection) | Команда разработки | Это уже более формально. Специалисты в данной области и разработчики проверяют код, чтобы убедиться, что он соответствует бизнес-целям и функциональным целям | Код готов к тестированию |
Test Plan Review (внутренней командой QA) | QA команда | План тестирования проходит внутреннюю проверку командой QA, чтобы убедиться в его точности и полноте | test plan готов к передаче внешним командам (Project Management, Business Analysis, development, Environment, client, etc.) |
Test Plan Review (внешнее) | Project Manager, Business Analyst, and Developer | Формальный анализ test plan, чтобы убедиться, что график и другие соображения команды QA соответствуют другим командам и всему проекту | Подписанный или утвержденный test plan, на котором будет основываться деятельность по тестированию |
Test documentation review (Peer review) | Членый команды QA | Экспертная проверка - это когда члены команды проверяют работу друг друга, чтобы убедиться, что в самой документации нет ошибок. | Документация по тестированию готова к передаче внешним командам |
Test documentation final review | Business Analyst and development team. | A test documentation review чтобы убедиться, что test cases охватывают все бизнес-условия и функциональные элементы системы | Тестовая документация готова к выполнению |
Валидация - это процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям клиентов, т.е. отвечает на вопрос: “правильный ли мы разработали продукт?”. Валидация является динамическим тестированием, т.е. происходит с помощью выполнения кода и прогона тестов на нём (UAT/CAT, usability, всё что угодно). Валидация является реактивным подходом (Reactive approach).
Если попробовать привести очень упрощенный пример, представим блюдо в ресторане. Верификация будет включать проверку технологической карты, оценку процесса приготовления (температуры, времени и т.п.). На протяжении этого процесса можно будет примерно быть уверенным, что блюдо получится именно тем, какое задумывалось и в итоге формально мы его приготовим. Валидация же - это, по сути, попробовать приготовленное блюдо, чтобы удостовериться, действительно ли получилось то, что ожидал бизнес и клиент.
Источник: Exact Difference Between Verification And Validation With Examples
Доп. материал:
Прежде всего, стоит разобраться с терминологией. В определениях Error/Mistake/Defect/Bug/Failure/Fault три из них переводятся на русский язык как ошибка. Определения из ISTQB:
Неофициальные же источники показывают более широкую картину:
Так что же такое баг на практике? Когда мы имеем ситуацию “1 требование = 1 тест-кейс”, то вопрос отпадает сам собой - тест-кейс не прошёл, значит требование реализовано не правильно, значит баг. Но обычно вариантов куда больше:
При этом часто может возникнуть извечный вопрос “баг или фича?”, когда баг-репорт заводить не нужно. Это фича-реквест, если:
Хорошо если в команде есть UX/UI дизайнер, а если нет? Тестировщику стоит различать что в дизайне баг, который может привести к печальным последствиям, а что запрос на улучшение, который сделает взаимодействие пользователей с системой более гладким и удобным, но может быть реализован позднее.
Классификация дефектов
Дефекты можно классифицировать по-разному. Для организации важно следовать единой схеме классификации и применять ее ко всем проектам. Некоторые дефекты можно отнести к нескольким классам или категориям. Из-за этой проблемы разработчики, тестировщики и сотрудники SQA должны стараться быть максимально последовательными при записи данных о дефектах.
Классы дефектов:
Некоторые специфические дефекты требований / спецификаций:
В англоязычной Wikipedia описано плюс-минус то же самое.
Жизненный цикл дефекта (Defect/Bug Life Cycle)
Жизненный цикл дефекта - это представление различных состояний дефекта, в которых он пребывает от начального до конечного этапа своего существования. Он может варьироваться от компании к компании и настраиваться под процессы конкретного проекта.
Статусы дефекта:
Утечка дефектов и релиз бага (Bug Leakage & Bug Release)
Утечка бага (Bug Leakage): возникает когда пропускается баг в билде, который вышел в Production. Если баг был обнаружен конечным пользователем или заказчиком, мы называем это утечкой ошибок.
Выпуск бага (Bug release): выпуск программного обеспечения в Production с некоторыми известными багами. Эти известные баги следует включить в примечания к выпуску (release notes). Другой вариант - передача программного обеспечения группе тестирования с некоторыми известными багами, серьезность и приоритет которых невысоки. Эти ошибки можно исправить перед выпуском в Production.
Основное отличие отладки от тестирования (Debugging Vs. Testing)
После того, как разработчик получил баг-репорт, он приступает к исправлению бага. Но, прежде чем ошибку исправить, нужно ее воспроизвести, понять, как она происходит и где ее найти в коде. Дебаг, буквально “de”+”bug” - это и есть процесс поиска и устранения ошибок в коде. Специальная debug-версия билда приложения может иметь расширенный вывод для более информативных логов или любые другие модификации для упрощения понимания проблемы. Тактика отладки может включать интерактивную отладку, анализ потока управления, модульное тестирование, интеграционное тестирование, анализ логов, мониторинг на уровне приложения или системы, дампы памяти и профилирование. Многие языки программирования и инструменты разработки программного обеспечения также предлагают программы для помощи в отладке, известные как отладчики/дебаггеры.
Маскировка дефектов (Defect masking)
Ситуация, когда наличие одного дефекта скрывает присутствие другого дефекта в системе.
Скрытый дефект (Latent defect)
Дефект, который является существующим дефектом в системе, но еще не вызывал сбоев, поскольку подходящий набор входных данных для его проявления не был введен или его проявлению мешает другой дефект (Defect masking).
Сортировка дефектов (Bug triage)
Это формальный процесс определения серьезности и приоритета дефектов в зависимости от их severity, риска, повторяемости и т. д. во время Defect Triage Meeting. Такая встреча полезна в условиях ограниченных ресурсов, когда нужно разобраться с множеством ошибок и тем, какие из них приоритетные.
Понятие сортировки пришло из медицины, где это процесс быстрого обследования пациентов, доставленных в больницу, чтобы решить, какие из них наиболее серьезно больны и нуждаются в лечении в первую очередь. В тестировании мы используем ту же концепцию к ошибкам, обнаруженным на этапе тестирования.
Источники:
Bug management включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении - баги, запросы на улучшения и даже целые релизы - обычно отслеживаются и управляются с помощью баг-трекинговых систем. Добавленные элементы могут называться дефектами, заявками, проблемами или, в соответствии с парадигмой гибкой разработки, эпиками и сторями (stories and epics). Категории могут быть объективными, субъективными или комбинированными, такими как номер версии, область программного обеспечения, серьезность и приоритет, а также тип проблемы, такой как фича-реквест или баг.
Критичность (severity): Важность воздействия конкретного дефекта на разработку или функционирование компонента или системы. (IEEE 610)
Приоритет (priority): Степень важности, присваиваемая объекту. Например, дефекту. (ISTQB)
Иными словами, серьезность представляет техническое влияние ошибки в контексте работоспособности самого ПО, а приоритет указывает на очередность выполнения задачи или устранения дефекта, т.е. точку зрения бизнеса. Приоритет выставляется любыми business stakeholders, включая project managers, business analysts, product owner, а серьезность сам тестировщик (или в сложных случаях тот, кто лучше разбирается). Разработчик берет таски исходя из приоритета.
Градация Серьезности (Severity):
Градация Срочности/приоритета (Priority):
Сочетания Severity и Priority
Источники:
Подход к тестированию - это реализация стратегии тестирования для конкретного проекта.
Подход к тестированию определяется и уточняется в test plans and test designs. Подход к тестированию обычно включает решения, принимаемые на основе цели (тестового) проекта и оценки рисков (risk assessment). Подход к тестированию является отправной точкой для планирования процесса тестирования, для выбора применяемых методов проектирования тестов и типов тестов, а также для определения критериев начала и окончания тестирования. Выбранный подход зависит от контекста и может учитывать риски, опасности и безопасность, доступные ресурсы и навыки, технологии, характер системы (например, custom built vs. commercially available off-the-shelf (COTS)), цели тестирования (test objectives) и правила.
Подход к тестированию включает две техники:
Различные подходы к тестированию:
Можно комбинировать разные подходы, например, динамический подход, основанный на оценке риска.
Источник:
ISTQB Foundation - 5.2.6 Test Strategy, Test Approach
Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Сложность современного ПО и инфраструктуры сделало невыполнимой задачу проведения тестирования со 100% тестовым покрытием. Поэтому для разработки набора тестов, обеспечивающего более-менее высокий уровень покрытия можно использовать специальные инструменты либо техники тест дизайна.
Существуют следующие подходы к оценке и измерению тестового покрытия:
Различия:
Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами разработанной части продукта (исходного кода), а анализ потока управления - на прохождении путей в графе или модели выполнения тестируемых функций (Control Flow Graph).
Ограничения:
Альтернативное мнение:
Покрытие кода — совершенно бесполезная метрика. Не существует «правильного» показателя. Это вопрос-ловушка. У вас может быть проект с близким к 100% покрытием кода, в котором по-прежнему остаются баги и проблемы. В реальности нужно следить за другими метриками — хорошо известными показателям CTM (Codepipes testing Metrics).
Источники:
Доп. материал:
Impact Analysis (импакт анализ) - это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты.
Затронутые области требуют большего внимания во время проведения регрессионного тестирования.
Импакт анализ может быть полезным в следующих случаях:
Как мы знаем, в настоящее время продукты становятся все более большими и комплексными, а компоненты все чаще зависят друг от друга. Изменение строчки кода в таком проекте может "сломать" абсолютно все.
Информация о взаимосвязи и взаимном влиянии изменений могут помочь QA:
Есть 3 типа импакт анализа:
...
Источники:
Доп. материал:
The Rise of Test Impact Analysis
Любой процесс, неважно, разработка это или тестирование, сопровождение, управление качеством и т.д., всегда должен быть цикличен. Существуют 4 основных подхода к работе с процессами, и самый популярный из них, это уже общепризнанный цикл Деминга. Именно на его основе строится работа процесса и все другие методологии, такие как DMAIC (6 сигм), IDEAL, EFQM, которые всегда говорят нам о том, что нужно не только требовать выполнение процесса, но и постоянно его анализировать и непрерывно совершенствовать. Эти модели позволяют нам понять, как мы должны работать с процессом, и самое главное, мы должны всегда видеть проблемы нашего процесса и стараться их решить.
Говоря о тестировании, существуют 2 основополагающих подхода к совершенствованию процесса тестирования, это MBI и ABI.
MBI или Model Based Improvement – подход к совершенствованию процесса тестирования, который основан на референтных моделях совершенствования процесса тестирования. Модели могут быть процессные, такие как TMMi, TPI и контекстные, такие как STEP или CTP. Эти модели позволяют нам на основе практик строить наш процесс тестирования по конкретным шагам, тем самым развивая процесс тестирования равномерно и последовательно.
Но подходят ли нам такие модели для аудитов уже существующих процессов?
Основная проблема в том, что каждый процесс тестирования различается в зависимости от организации, что ставит по сомнение применение тех практик, которые дает нам модельный подход. Ну и многие специалисты, которые проводили именно аудит процесса тестирования возможно слышали фразу, ставящую в тупик все результаты вашей работы: “Я могу сейчас взять ваши результаты, принести их в другую компанию и они тоже там будут применимы. Нет конкретики!” И все это потому, что многие руководители, тест-менеджеры, особенно в России, не понимают различия между аудитом и оценкой уровня зрелости процесса тестирования.
Аудит – это анализ текущего состояния процесса с целью решения конкретных проблем, не позволяющих процессу выполнять поставленные задачи.
Оценка зрелости – это анализ текущего состояния процесса с целью понимания его зрелости относительно общепринятых моделей процесса тестирования. Оценка уровня зрелости зачастую может не решать вообще никаких проблем, т.к. ее задача только оценить процесс.
Поэтому, говоря о модельном подходе MBI разумно его применять только для выполнения задач по оценке уровня зрелости процесса тестирования и написанию стратегии развития процесса тестирования на длительных срок. Во всех остальных случаях, а особенно, когда вам нужно решить какую-то проблему, MBI не поможет вам. Для это существует подход ABI.
ABI или Analytical Based Improvement – это подход к совершенствованию процесса тестирования, который основывается на аналитических подходах анализа процесса.
Главное отличие модельного подхода от аналитического в том, что когда мы анализируем процесс по MBI, то мы анализируем процесс сверху вниз, то есть, сначала мы смотрим на процесс в целом, потому делим его на области, этапы и т.д., тем самым постепенно погружаясь в детали процесса. Аналитический подход работает наоборот, мы сначала погружаемся в самые детали нашего процесса и уже потом идя, как по цепочке, вверх, доходим до решения нашей главной проблемы.
Существуют несколько аналитических подходов к совершенствованию процессов, но я ни разу не видел их применение к процессу тестирования, т.к. они содержат именно модель анализа и могут быть применимы, в том числе, и в производстве фабрики, расследовании аварий, построении мостов и многом многом другом.
Задайте себе вопрос, как часто к вам приходил ваш руководитель со словами, у нас есть такая проблема в процессе и ее нужно решить? Что вы делаете? Вы ищете причину этой проблемы и пытаетесь ее устранить. Но очень часто бывает так, что вроде вы решаете причину, но процесс все равно не работает как надо. И все это потому, что вы выбрали для решения не то узкое место!
Поэтому для проведения аудита процесса тестирования, с целью решения конкретных проблем стоит обратить свое внимание на Root Cause Analysis.
Анализ первопричин (RCA) - это систематический процесс выявления скрытых первопричин проблем или событий и подхода к их устранению. В основе RCA лежит основная идея о том, что эффективное управление требует большего, чем просто «тушение пожаров» возникающих проблем, но и поиск способов их предотвращения. Таким образом RCA представляет собой древовидную иерархическую структуру зависимости причин, как с проблемой, так и между собой.
Стандартно, к проблемам процесса тестирования, я отношу только те проблемы, которые связаны с классическим треугольником – цена/качество/сроки. Почему это так? Любой процесс ИТ, в том числе и тестирование, должен обеспечивать бизнес организации. ИТ – это помощник бизнеса, поэтому, когда вам бизнес говорит, что они не успевают внедрять все запланированные фичи, продукты, то это не проблема бизнеса (что они генерят много задач), а проблема тестирования. Все остальное, что не связано с этим “треугольником проблем” является причинами возникновения проблем, которые зачастую бывают непонятны и скрываются от нас.
Процесс аудита по RCA состоит из 5 этапов:
Итак, что такое проблема? Проблема – это вопрос или задача, требующая разрешения. Проблемы в нашей работе мы находим постоянно, критичность проблемы мы определяем симптомами, т.е. признаками существования проблемы. Допустим, мы идентифицировали проблему, как постоянный сдвиг сроков внедрения релиза. Признаком существования в проблемы в данном случае может быть систематичность ее возникновения. Я думаю, вы понимаете разницу, один раз у вас произошел сдвиг за 6 релизов, или уже 6-й раз подряд. Во втором случае проблема уже начинает носить критический характер. Решать все проблемы невозможно, поэтому если у Вас есть большое количество проблем, то вы можете выбрать наиболее важные из них по степени влияния и частоте возникновения.
Имея проблему, мы можем приступать к поиску вероятностных причин. Самый простой способ определения причин – метод брейншторма всех вовлеченных в процесс участников. Вы можете собрать со всех специалистов их мнение относительно того, какие они видят причины возникновения проблемы и после этого выбрать из них наиболее часто называемые сотрудниками.
Следующий и очень важный шаг – это анализ вероятностных причин.
Существуют несколько подходов к проведению анализа, таких как диаграммы зависимостей или рассеивания, аффинная диаграмма, но самым распространенным подходом к проведению анализа является диаграмма Парето.
Путем брейншторма мы определили 5 основных причин возникновения проблемы, связанной со сдвигом сроков внедрения. После этого наша задача понять, какие из этих причин наиболее серьезно влияют на нашу проблему. Используя принцип Парето мы определяем количество человеко-дней, которые мы теряем из-за возникновения той или иной проблемы.
В результате анализа мы видим, что только первые 2 причины на 60% влияют на сдвиг сроков внедрения, что существенно больше, чем остальные 3 причины суммарно.
Следующим этапом является проведение причинно-следственного анализа (ПСА) с целью выявления коренных причин и их зависимостей друг с другом. Для этого используется диаграмма причинно-следственного анализа, основная задача которой заключается в том, что идя от проблемы по цепочке мы погружаемся на каждом уровне в причины возникновения причин, тем самым доходя до истинной или коренной причины возникновения проблем. В результате, решив коренную причину, мы автоматически решаем все остальные наши причины, что приводит к минимизации влияния или полного устранения нашей проблемы.
Для выполнения ПСА мы наносим на наше дерево все наши причины, которые были определены ранее принципом Парето. После это мы их приоритезируем и определяем их взаимозависимость. Например, говоря о тестовых средах, а именно проблемах ,связанных с подбором тестовых данных, это приводит к возникновению дефектов “тестирования”, что увеличивает сроки выполнения работ по тестированию ПО. Соответственно, решив эту причину, мы автоматически сможем снизить влияние причины, связанной с дефектами. Поэтому, мы можем решать не 3 причины, а всего 2, тем самым сокращая затраты на оптимизацию процесса тестирования.
Ну и заключительный этап – это выработка решений. Проведя анализ RCA решения будут уже вполне понятны, но очень важно, чтобы эти решения действительно были нацелены на конкретную причину и были выполнимы всей командой, на которую ложится их реализация.
Наиболее понятной книгой, рассматривающей модель RCA, я считаю Андерсон Бьерн — «Анализ основной причины. Упрощенные инструменты и методы», в которой на обычных жизненных примерах рассматриваются различные возможности применения модели RCA.
Поэтому, если Вам поставили задачу оптимизировать ваш процесс тестирования, но для этого вам нужно решить какие-то текущие проблемы, то вам нужен аудит с применением ABI, т.к. именно ABI позволяют точечно решать проблемы и любые ваши рекомендации будут носить не рекомендательный характер, а детальный, направленный на оптимизацию именно для вашего проекта или процесса.
Источник:
Root Cause Analysis. Как минимизировать затраты на оптимизацию процесса тестирования
Доп. материал:
Существует определение Maturity Models, то есть модели зрелости различных процессов в организации, состоящая из 5 уровней. Нас же в рамках этого материала интересует один конкретный подвид моделей MM - модель зрелости тестирования, которая тоже состоит из 5 уровней. TMM основан на модели зрелости возможностей (CMM — Capability Maturity Model). Модель зрелости ПО (CMM или SW-CMM) — это модель для оценки зрелости программных процессов в организации. В ней также перечислены некоторые стандартные практики, которые увеличивают зрелость этих процессов. TMM это подробная модель для улучшения процесса тестирования. Она может быть дополнена любой моделью улучшения процесса или может использоваться как одиночная модель.
Модель ТММ имеет два основных компонента:
Пять уровней TMM помогают организации определить зрелость своего процесса и определить следующие шаги по улучшению, которые необходимы для достижения более высокого уровня зрелости тестирования.
Доп. материал:
Тестирование со сдвигом влево - это практика включения тестирования на более ранних этапах SDLC. Конечная цель состоит в том, чтобы тестировщики работали вместе с командой разработчиков на ранних этапах разработки, чтобы те могли работать над предотвращением проблем до их возникновения, а не выявлять их в конце проекта. Тестируя на раннем этапе, тестировщики могут сократить время, необходимое для проведения тестовых спринтов, могут помочь повысить качество программного обеспечения и помочь устранить фатальные проблемы, которые обычно обнаруживаются в конце.
Доп. материал:
Можете ли вы доверять вердикту судьи, который является частью внутреннего круга людей, которых он должен судить? Чтобы этот процесс был справедливым, лица, принимающие решения, должны быть беспристрастными. Теперь, когда вы активно участвуете в разработке какого-либо продукта или программного обеспечения, тестировать его с нейтральным мышлением это легче сказать, чем сделать. Вы бы хотели отгружать продукт в кратчайшие сроки и считать его безупречным и в конечном итоге упустите из виду некоторые ошибки. Чтобы избежать такой ситуации, иногда следует нанять независимую организацию по тестированию.
Тестирование по уровням независимости:
Источник:
Independent Testing Guide – How It Delivers Quality Driven Product
Это модель аутсорсинга, при которой деятельность по тестированию передается третьей стороне. Здесь тестирование проводится сторонними подрядчиками, а не сотрудниками организации. TaaS используется, когда Компании не хватает навыков или ресурсов для внутреннего тестирования или чтобы получить свежий взгляд со стороны. Чаще всего на аутсорс отдают тестирование функциональности, производительности и безопасности.
Источник: Software Testing as a Service (TaaS)
Альфа- и бета-тестирование - это Customer Validation methodologies (Acceptance Testing types) которые помогают укрепить веру в запуске продукта и, таким образом, привести к успеху продукта на рынке. Несмотря на то, что они оба полагаются на реальных пользователей и обратную связь разных команд, ими движут разные процессы, стратегии и цели. Эти два типа тестирования вместе увеличивают успех и продолжительность жизни продукта на рынке. Эти этапы можно адаптировать к продуктам Consumer, Business или Enterprise. Этапы альфа- и бета-тестирования в основном сосредоточены на обнаружении ошибок в уже протестированном продукте и дают четкое представление о том, как продукт на самом деле используется пользователями в реальном времени. Они также помогают получить опыт работы с продуктом перед его запуском, а ценные отзывы эффективно используются для повышения удобства использования продукта. Цели и методы альфа- и бета-тестирования переключаются между собой в зависимости от процесса, которому следуют в проекте, и могут быть изменены в соответствии с процессами.
Альфа-тестирование - это форма внутреннего приемочного тестирования (internal acceptance testing), выполняемого, в основном, собственными командами по обеспечению качества и тестированию ПО. Альфа-тестирование - это последнее тестирование, проводимое группами тестирования на месте разработки после приемочного тестирования и перед выпуском программного обеспечения для бета-тестирования. Альфа-тестирование также может быть выполнено потенциальными пользователями или клиентами приложения. Но все же это форма внутреннего приемочного тестирования.
Бета-тестирование - это следующий этап после альфа-тестирования. Это заключительный этап тестирования, на котором компании выпускают ПО для нескольких внешних групп пользователей, не входящих в группы тестирования компании или сотрудников. Эта начальная версия программного обеспечения известна как бета-версия. Большинство компаний собирают отзывы пользователей в этом выпуске. Короче говоря, бета-тестирование можно определить как тестирование, проводимое реальными пользователями в боевой среде. Несмотря на то, что компании проводят строгую внутреннюю проверку качества с помощью специальных групп тестирования, практически невозможно протестировать приложение для каждой комбинации тестовой среды. Бета-версии упрощают тестирование приложения на тысячах тестовых машин и исправление проблем перед выпуском приложения для широкой публики. Выбор групп для бета-тестирования может производиться в зависимости от потребностей компании. Компания может либо пригласить нескольких пользователей для тестирования предварительной версии приложения, либо выпустить ее открыто, чтобы это мог сделать любой. Устранение проблем в бета-версии может значительно снизить затраты на разработку, поскольку большинство незначительных сбоев будут исправлены до окончательной версии. До сих пор многие крупные компании успешно использовали бета-версии своих самых ожидаемых приложений.
Alpha Testing | Beta Testing |
Testing environment | Real environment |
Functional, usability | Functional, Usability, Reliability, Security |
White box and / or Black box testing | Black box testing |
На найденные дефекты создаются баг-репорты с high priority, после чего они немедленно исправляются | Дефекты собираются из обратной связи от пользователей и записываются как улучшения для будущей версии |
Цели:
| Цели:
|
Когда?
| Когда?
|
Продолжительность теста:
| Продолжительность теста:
|
Stakeholders: Engineers (in-house developers), Quality Assurance Team, and Product Management Team | Stakeholders: Product Management, Quality Management, and User Experience teams |
Участники:
| Участники:
|
Ожидания:
| Ожидания:
|
Критерии начала (Entry Criteria):
| Критерии начала (Entry Criteria):
|
Критерии окончания (Exit Criteria):
| Критерии окончания (Exit Criteria):
|
Плюсы (Pros):
| Плюсы (Pros):
|
Минусы (Cons):
| Минусы (Cons):
|
Помимо альфа- и бета-тестирования, существуют еще гамма-тестирования и пилотное.
Gamma Testing - это заключительный этап тестирования, который выполняется, когда продукт готов к выпуску с особыми требованиями. Не все действия по внутреннему тестированию, которые решено пройти через этот этап тестирования, выполняются на продукте. Этот этап не позволяет вносить в продукт какие-либо изменения, кроме исправления критических ошибок, которые необходимо выполнить. Это тестирование проводится, чтобы убедиться, что продукт является более безопасным с точки зрения качества продукта, удобства использования, безопасности и производительности перед выпуском в прод.
Pilot testing определяется как тип тестирования программного обеспечения, который проверяет компонент системы или всю систему в режиме реального времени. Целью пилотного теста является оценка осуществимости, времени, стоимости, риска и эффективности исследовательского проекта. Это тестирование проводится точно между UAT и Production. В пилотном тестировании выбранная группа конечных пользователей пробует тестируемую систему и предоставляет обратную связь до полного развертывания системы. Другими словами, это означает проведение генеральной репетиции для последующего теста на удобство использования. Пилотное тестирование помогает в раннем обнаружении ошибок в Системе. Пилотное тестирование связано с установкой системы на площадке заказчика (или в среде, моделируемой пользователем) для тестирования на предмет постоянного и регулярного использования. Выявленные недостатки затем отправляются команде разработчиков в виде отчетов об ошибках, и эти ошибки исправляются в следующей сборке системы. Во время этого процесса иногда приемочное тестирование также включается как часть тестирования на совместимость. Это происходит, когда система разрабатывается для замены старой.
Источник:
Alpha Testing And Beta Testing (A Complete Guide)
Продукта без требований не существует, просто они могут быть не формализованы и не записаны. Если вам дали протестировать какое-то готовое решение, к которому нет документации, то нужно попытаться восстановить все явные и неявные требования: изучив функционал (какую проблему решает продукт? для чего его создали?), целевую аудиторию (для кого его создали?), попытаться найти тех, кто мог знать что-то и уже не в команде; список источников получения неявных требований вообще огромен. На основе всего этого уже как минимум можно составить user stories для покрытия основными тестами.
Доп. материал:
Тестирование без требований. Где искать требования к продукту, если отсутствует ТЗ?
Роли в тестировании ПО:
Источники:
Доп. материал:
В общем случае среда тестирования - это конфигурация ПО/виртуального контейнера и/или сервера, т.е. эдакая песочница для тестирования. Позволяет не испытывать судьбу с production-версией, а также дает множество возможностей, которые недоступны на боевом окружении. Существует несколько сред:
Испытательный стенд (Test Bed) – более глобальная сущность и включает в себя operating system, configuration management for the products, hardware, network topology и т. д. Настраиваются в соответствии с требованиями тестируемого приложения. В некоторых случаях испытательный стенд может представлять собой комбинацию тестовой среды и тестовых данных, которые он использует.
Настройка правильной среды тестирования гарантирует успех тестирования ПО. Любые недостатки в этом процессе могут привести к дополнительным затратам и времени для клиента. Следующие люди участвуют в настройке тестовой среды: Системные администраторы, Разработчики, Тестировщики.
Доп. материал:
Тестовые данные - это набор входных значений, необходимых для выполнения Test case. Тестировщики определяют данные в соответствии с требованиями. Они могут сделать это вручную или использовать инструменты генерации.
Доп. материал:
What Is Test Data? Test Data Preparation Techniques With Example
Бизнес-логика - это реализация работы бизнес-процессов внутри ПО, т.е. это реализация предметной области (domain) в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
Источники:
Она означает, что все баги имеют приоритет над разработкой новых фич или улучшениями. Важным следствием этого подхода является отсутствие таких вещей, как приоритет багов, critical bugs или minor bugs. Либо issue является багом, либо нет. И если это баг, вам нужно исправить его, прежде чем выполнять другую работу.
Преимущества:
Источник:
Доп. материал:
Эвристики – это быстрые, недорогие способы решения проблемы или принятия решения. В мире тестирования ПО мы можем использовать эвристики как выведенные опытным путём подсказки для принятия решений и решения проблем в ходе тестирования. Они могут быть особенно полезными для генерации предположений, если мы не уверены, как начать тестирование, или исчерпали идеи, что делать дальше.
Мнемоника – это тип эвристики, набор правил и приемов, которые помогают эффективно запоминать необходимые сведения (информацию), обычно это слово-аббревиатура или фраза. Например, все помнят детскую мнемонику “каждый охотник желает знать где сидит фазан”, в которой по первым буквам каждого слова можно вспомнить порядок цветов радуги.
Множество известных тест-эвристик использует мнемоники и широко распространено заблуждение, что у эвристик должна быть мнемоника, или что это одно и то же. Это не так. Эвристики не требуют мнемоник, они просто создаются таким образом, чтобы их было легче запомнить.
Эвристики и мнемоники могут быть придуманы, модифицированы и скрещены как удобно автору для своих нужд. Вот наиболее известные:
Расшифровка, больше вариантов и дополнительные ссылки в первом источнике.
Эвристики окончания тестирования (когда пора прекратить тестировать продукт):
Дополнение: Кем Канер (Cem Kaner) предложил еще одну эвристику: «Отказ от выполнения задания» (Mission Rejected), в которой тестировщик сам отказывается от продолжения тестирования.
Источники:
Примечание: понятие типов, методов и видов в англоязычной литературе часто не разделяется и может быть перечислено вообще вперемешку, а также зачастую там выделяют только функциональное и нефункциональное тестирование. Не зацикливайтесь на категоризации и терминологии, пытайтесь понять саму суть.
Самым высоким уровнем в иерархии подходов к тестированию будет понятие типа/метода, которое может охватывать сразу несколько смежных техник тестирования. То есть, одному типу тестирования может соответствовать несколько его видов. Отличаются они знанием внутреннего устройства объекта тестирования.
Доп. материал:
What is red box, yellow box and green box testing?
Другие названия: Behavioral Testing, Specification-Based Testing, Input-Output Testing, непрозрачный ящик (opaque-box), закрытый ящик (closed-box), тестирование на основе спецификации (specification-based testing) или тестирование с глазу на глаз (eye-to-eye testing).
Тестирование методом «черного ящика» - это стратегия, в которой тестирование основано исключительно на требованиях и спецификациях, при этом мы не знаем, как устроена внутри тестируемая система и работаем исключительно с внешними интерфейсами тестируемой системы или компонента. Тестирование черного ящика может быть применено на всех уровнях - модульном, интеграционном, системном и приемочном.
Functional Testing: этот тип касается функциональных требований или спецификаций приложения (functional requirements or specifications). Здесь различные действия или функции системы тестируются путем предоставления входных данных и сравнения фактического выхода с ожидаемым выходом. Например, когда мы тестируем раскрывающийся список, мы нажимаем на него и проверяем, что он раскрывается и все ожидаемые значения отображаются. Вот несколько основных типов функционального тестирования:
Non-Functional Testing: Помимо функциональности требований, есть несколько нефункциональных аспектов, которые необходимо протестировать, чтобы улучшить качество и производительность приложения. Несколько основных типов нефункционального тестирования включают:
Преимущества Black box testing:
Недостатки Black box testing:
Парадигмы тестирования методом черного ящика (Paradigms of Black Box Software Testing)
Парадигма создает основное направление мышления - она дает понимание и направление для дальнейших исследований или работы. Парадигма тестирования будет определять типы тестов, которые (для человека, работающего в рамках этой парадигмы) актуальны и интересны. Список парадигм:
Источники:
Тестирование методом белого ящика (также: прозрачного, открытого, стеклянного ящика; основанное на коде или структурное тестирование) - метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тому, кто её тестирует. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации – обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы, за пределы ее внешних интерфейсов.
Техника белого ящика применима на разных уровнях тестирования - модульном, интеграционном и системном, но чаще применяется для юнит-тестирования этого участка кода самим разработчиком или SDET. Тестирование белого ящика - это больше, чем тестирование кода: это тестирование путей. Обычно тестируемые пути находятся внутри модуля (модульное тестирование). Но мы можем применить эту же методику для тестирования путей между модулями внутри подсистем, между подсистемами внутри систем, и даже между целыми системами.
Тестирование белого ящика - это покрытие требований в коде:
Используя покрытие Statement и Branch, вы обычно достигаете 80-90% покрытия кода, что является достаточным.
Процесс White box testing:
Преимущества White box testing:
Недостатки White box testing:
White box testing нужно:
Чтобы убедиться, что:
Чтобы обнаружить следующие типы ошибок:
Источники:
Тестирования методом серого ящика вообще нет в ISTQB, тем не менее много где можно встретить упоминания этого типа тестирования. В целом оно определяется как метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов или как дополненный черный ящик. Т.е., внутреннее устройство/код известны/используется лишь частично, и, например, имея доступ к внутренней структуре и алгоритмам работы ПО, можно написать более эффективные тест-кейсы, но само тестирование проводится с помощью техники черного ящика, то есть, с позиции пользователя.
Примеры: тестирование с проверкой корректности записей в БД; работа с логами и метриками для поиска root cause проблем.
Техники:
Источник: Grey Box Testing Tutorial With Examples, Tools And Techniques
Статическое тестирование (Static Testing, Non-execution technique или verification) подразумевает проверку вручную или с помощью инструментов кода без его запуска и всей документации.
Почему требуется статическое тестирование:
Динамическое тестирование (Dynamic Testing, Execution technique или validation) подразумевает запуск кода для проведения функциональных и нефункциональных проверок ПО. Основная цель этого тестирования - подтвердить, что программный продукт работает в соответствии с требованиями бизнеса. Преимуществами динамического тестирования являются выявление сложных дефектов, которые не могут быть обнаружены статическим тестированием, обнаружение угроз безопасности, проблем с производительностью и т.п.
Источник:
«Пирамида тестов» — метафора, которая означает группировку динамических тестов программного обеспечения по разным уровням. Она также дает представление, какое количество тестов должно быть в каждой из этих групп. Основной принцип разделения уровней - тест должен быть на том же уровне, что и тестируемый объект. В тесте более высокого уровня вы не тестируете всю условную логику и пограничные случаи, которые уже покрыты тестами более низкого уровня.
Уровни тестирования:
Доп. материал:
С этими терминами часто происходит путаница. Если ссылаться на глоссарий ISTQB, то все они - синонимы:
Тем не менее, некоторые источники описывают ситуацию несколько иначе и я решил выписать другую точку зрения.
Модульное тестирование (оно же юнит-тестирование) используется для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками. Целью тестирования модуля является не демонстрация правильного функционирования модуля, а демонстрация наличия ошибки в модуле, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования. Изоляция тестируемого блока достигается с помощью заглушек (stubs), манекенов (dummies) и макетов (mockups).
Компонентное тестирование — тип тестирования ПО, при котором тестирование выполняется для каждого отдельного компонента отдельно, без интеграции с другими компонентами. Его также называют модульным тестированием (Module testing), если рассматривать его с точки зрения архитектуры. Как правило, любое программное обеспечение в целом состоит из нескольких компонентов. Тестирование на уровне компонентов (Component Level testing) имеет дело с тестированием этих компонентов индивидуально. Это один из самых частых типов тестирования черного ящика, который проводится командой QA. Для каждого из этих компонентов будет определен сценарий тестирования, который затем будет приведен к Test case высокого уровня -> детальным Test case низкого уровня с предварительными условиями.
Исходя из глубины уровней тестирования, компонентное тестирование можно классифицировать как:
Module/Unit testing | Component testing |
Тестирование отдельных классов, функций для демонстрации того, что программа выполняется согласно спецификации | Тестирование каждого объекта или частей программного обеспечения отдельно с или без изоляции других объектов |
Проверка в(на) соответствии с design documents | Проверка в(на) соответствии с test requirements, use case |
Пишутся и выполняются разработчиками | Тестировщиками |
Выполняется первым | Выполняется после Unit |
Другой источник:
По-существу эти уровни тестирования представляют одно и тоже, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном/unit тестировании - конкретные значения.
*В контексте юнит-тестирования еще можно встретить понятие golden testing. Оно означает те же юнит тесты, но с ожидаемыми результатами хранящимися в отдельном файле. Таким образом после прогона выходные значения тестов сравниваются с golden (эталонным) файлом.
*Иногда юнит-тесты называют одинокими (solitary) в случае тотального применения имитаций и заглушек или общительными (sociable) в случае реальных коммуникаций с другими участниками.
*Правило трех А(AAA) (arrange, act, assert) или триада «дано, когда, тогда» — хорошая мнемоника, чтобы поддерживать хорошую структуру тестов.
Источники:
Доп. материал:
Интеграционное тестирование предназначено для проверки насколько хорошо два или более компонента ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). С технологической точки зрения интеграционное тестирование является количественным развитием компонентного, поскольку также оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки (Stub) на месте отсутствующих модулей. Основная разница между компонентным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. В частности, на уровне интеграционного тестирования часто применяются методы, связанные с покрытием интерфейсов, например, вызовов функций или методов, или анализ использования интерфейсных объектов, таких как глобальные ресурсы, средства коммуникаций, предоставляемых операционной системой.
Уровни интеграционного тестирования:
Интеграция может быть как программной, так и софт-железо:
Подходы к интеграционному тестированию:
Критерии начала и окончания Integration Testing:
Обычно при выполнении интеграционного тестирования используется стратегия ETVX (Entry Criteria, Task, Validation, Exit Criteria).
Test Harness- это набор заглушек, драйверов и других вспомогательных инструментов, необходимых для объединения двух компонентов кода или модуля, которые взаимодействуют друг с другом, чтобы проверить, соответствует ли комбинированное поведение ожидаемому или нет.
Test Driver и Test Stub являются искусственными заменами компонентов программы на время тестов по аналогии с моками в тестировании API. Тестовый драйвер - то, что вызывает тестируемый компонент. Тестовая заглушка - то, что возвращает тестируемому компоненту фиктивный ответ. Т.е. заглушки и драйверы не реализуют всю логику программного модуля, а только моделируют обмен данными с тестируемым модулем.
Тестирование интерфейса - это тип интеграционного теста, который проверяет, правильно ли установлена связь между двумя различными программными системами или их частями (модулями). Соединение, которое объединяет два компонента, называется интерфейсом. Этот интерфейс в компьютерном мире может быть чем угодно, как API, так и веб-сервисами и т. д. Тестирование интерфейса включает в себя тестирование двух основных сегментов:
Тестирование потоков (Thread testing) - это вид тестирования программного обеспечения, который проверяет основные функциональные возможности конкретной задачи (потока). Обычно проводится на ранней стадии фазы интеграционного тестирования. Тестирование на основе потоков является одной из дополнительных стратегий, принятых в ходе System Integration Testing. Поэтому его, вероятно, следует более правильно назвать «тестом взаимодействия потоков» (thread interaction test).
Thread Testing подразделяется на две категории:
Как проводить Thread Testing:
Советы:
Источники:
Доп. материал:
Системное тестирование означает тестирование всей системы в целом, оно выполняется после интеграционного тестирования, чтобы проверить, работает ли вся система целиком должным образом. В основном это тестирование типа «черный ящик», которое оценивает работу системы с точки зрения пользователя с помощью документа спецификации и оно не требует каких-либо внутренних знаний о системе, таких как дизайн или структура кода.
Основное внимание уделяется следующему:
Зачем нужно системное тестирование?
Критерии начала системного тестирования:
Критерии окончания системного тестирования:
Чем отличается системное тестирование от сквозного (E2E - end-to-end testing)?
Сквозное тестирование - это методология тестирования программного обеспечения для тестирования flow приложения от начала до конца. Целью сквозного тестирования является моделирование реального пользовательского сценария и проверка тестируемой системы и ее компонентов на предмет интеграции и целостности данных.
Системное тестирование - этап предпоследний этап STLC и уровень тестирования, а E2E - подход к тестам. Обычно сквозные тесты выполняют после системного тестирования и перед приемочным, а также после внесения изменений (smoke и regression). E2E выполняется от начала до конца в реальных сценариях, таких как взаимодействие приложения с оборудованием, сетью, базой данных и другими приложениями. Основная причина проведения этого тестирования - определение различных зависимостей приложения, а также обеспечение передачи точной информации между различными компонентами системы.
Источники:
Доп. материал:
Лекция 7: Разновидности тестирования: системное и регрессионное тестирование
После того, как процесс тестирования системы завершен командой тестирования, весь продукт передается клиенту и/или нескольким его пользователям для проверки приемлемости (acceptability). Е2Е бизнес-потоки проверяются аналогично в сценариях в реальном времени. Подобная производственной среда будет тестовой средой для приемочного тестирования (Staging, Pre-Prod, Fail-Over, UAT environment). Это метод тестирования черного ящика, при котором проверяется только функциональность, чтобы убедиться, что продукт соответствует указанным критериям приемки.
Виды приемочного тестирования:
Источники:
Доп. материал:
Вообще виды тестирования можно классифицировать по самым разным критериям, поэтому можно встретить и такие схемы:
Еще классификаций на десерт: exploratory vs scripted; traditional vs agile; testing vs checking; standards-driven vs context-driven; phased vs. threaded.
Доп. материал:
Функциональное тестирование выполняется чтобы убедиться, что каждая функция программного приложения ведет себя так, как указано в документе с требованиями. В большинстве случаев это выполняется методом black box testing.
Для функционального тестирования принято использовать две техники:
Основные виды функционального тестирования:
Критерии начала функционального тестирования:
Критерии окончания функционального тестирования:
Этапы функционального тестирования:
Источник: Complete Functional Testing Guide With Its Types And Example
Нефункциональное тестирование проводится для проверки нефункциональных требований приложения, таких как производительность, безопасность, совместимость, надежность, удобство использования и т. д. В большинстве случаев это выполняется методом black box testing. Оно проверяет, соответствует ли поведение системы требованиям по всем аспектам, не охваченные функциональным тестированием. В нашем повседневном тестировании много внимания уделяется функциональному тестированию и функциональным требованиям и клиенты также заинтересованы в выполнении функциональных требований, которые напрямую связаны с функциональностью приложения, но когда ПО выходит на рынок и используется реальными конечными пользователями, у них есть шансы столкнуться с проблемами. Эти проблемы не связаны с функциональностью системы, но могут негативно повлиять на пользовательский опыт.
Нефункциональные требования могут быть отражены как:
Документ подхода к тестированию (Approach Document):
Разработайте конкретный подход к этапу тестирования, уточнив общую стратегию тестирования. Этот подход к тестированию помогает при планировании и выполнении всех задач тестирования:
Виды нефункционального тестирования (список не полный):
Примеры чек-листов:
Тестирование производительности:
Тестирование безопасности:
Тестирование документации:
Источник: A Complete Non-Functional Testing Guide For Beginners
Тестирование производительности - это нефункциональный вид тестирования программного обеспечения, используемый для проверки скорости, времени отклика, стабильности, надежности, масштабируемости и использования ресурсов программного приложения при определенной рабочей нагрузке, обычно регрессионным образом, когда в приложение ежедневно или еженедельно вносятся небольшие изменения. Основная цель тестирования производительности - выявить и устранить узкие места производительности в программном приложении. Это подмножество performance engineering, также известное как «Perf Testing». Само по себе оно не призвано находить дефекты, но оно помогает в обнаружении узких мест в системе.
Обычно продолжительность теста производительности составляет 1 час (устойчивое состояние) на средней / ожидаемой нагрузке; это может варьироваться в зависимости от вашего SLA / требований.
Примечание 1: все подвиды тестирования производительности отличаются, грубо говоря, только параметрами (тип возрастания нагрузки, ее количество, длительность и т.п.) и собираемыми метриками (без которых это тестирование бессмысленно). Точкой отсчета для всех подвидов принято брать результаты Capacity testing.
Примечание 2: несмотря на необходимость понимания многих математических и статистических концепций, многие тестировщики и менеджеры либо не имеют достаточных знаний в области математики и статистики, либо не пользуются ими. Это приводит к значительным искажениям и неверной интерпретации результатов тестирования производительности (те же перцентили).
Общие проблемы с производительностью.
Большинство проблем с производительностью связаны со скоростью, временем отклика, временем загрузки и плохой масштабируемостью. Скорость часто является одним из самых важных атрибутов приложения. Медленно работающее приложение потеряет потенциальных пользователей. Тестирование производительности проводится для того, чтобы убедиться, что приложение работает достаточно быстро, чтобы удерживать внимание и интерес пользователя. Взгляните на следующий список распространенных проблем с производительностью и обратите внимание на то, что скорость является общим фактором во многих из них:
Как проводить тестирование производительности?
Метрики тестирования производительности (Performance Testing Metrics):
Тестирование производительности клиентской части и серверной, в чем разница?
Оценка скорости работы клиентской и серверной частей веб-приложения осуществляется двумя разными видами тестирования: для Frontend применяется тестирование клиентской части, или Client-Side testing, а для Back-end – тестирование серверной части.
Основная цель тестирования клиентской части состоит в измерении времени, необходимого браузеру для загрузки HTML-страницы. Наиболее важными показателями здесь являются количество загружаемых данных, их объем, а также количество выполненных запросов.
Собрать данную статистику можно как с использованием встроенных инструментов браузера (DevTools), так и с помощью специализированных инструментов и онлайн-сервисов, которые позволяют замерить необходимые показатели с учетом интересующего региона.
Помимо общего веса страницы, инструменты предоставляют детализированную информацию по каждому из компонентов. Изучив параметры запросов, можно обнаружить ряд проблем, приводящих к ухудшению скорости отображения страницы. К примеру, подгружается слишком большая картинка, медленный Javascript, или отправляется значительное количество запросов.
Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.
Тестирование серверной части направлено на анализ выполнения запросов и получения соответствующего ответа от Back-end.
Цели данного вида тестирования:
Примеры проверок:
Во время фактического выполнения теста производительности расплывчатые термины, такие как допустимый диапазон, большая нагрузка и т. д., Заменяются конкретными цифрами. Инженеры по производительности устанавливают эти числа в соответствии с бизнес-требованиями и техническим ландшафтом приложения.
Источники:
Доп. материал:
Capacity — базовый тест, который обычно выполняется первым. Все последующие тесты на среднее время ответа, регенерацию системы, утилизацию ресурсов нужно выполнять с оглядкой на результаты Capacity.
Тестирование емкости гарантирует, что приложение и среда могут беспрепятственно обрабатывать максимальное количество пользователей или транзакций в соответствии с требованиями к производительности, определенными в вашем соглашении об уровне обслуживания (SLA). Тестирование емкости нацелено на тестирование максимальной емкости вашей системы с точки зрения трафика, при этом обеспечивая оптимальное взаимодействие с пользователем. Общие примеры SLA по производительности включают время загрузки домашней страницы, время ответа веб-страницы, продолжительность транзакции (например, - время входа в учетную запись, время поиска и платежа). Общая цель состоит в том, чтобы идентифицировать «зону безопасности» системы и удерживать ее в максимально возможной степени. Тестирование емкости помогает определить, в какой степени она может быть расширена без ущерба для опыта конечного пользователя.
Емкость системы измеряется в rps (requests per second). Используемый подход: ступенчато повышаем нагрузку до момента, когда время ответа начнет расти экспоненциально. Экспоненциальный рост времени ответа, как правило, связан с полной утилизацией одного из ресурсов, из-за которого запросы вместо моментальной обработки выстраиваются друг за другом и ждут своей очереди на обработку.
Обратите внимание: от 1 до 12 rps процентиль времени ответа практически не изменяется. Только на 13 и 14 rps мы видим незначительный рост, который не изменяется с течением времени. Это значит, что мы практически исчерпали ресурс, в который упремся, но очередь еще не образуется. На 15 rps время ответа начало расти экспоненциально, значит это и есть наш предел. Таким образом, можно сделать вывод, что емкость =14 rps. Следующий шаг — поиск ресурса который исчерпался и не дает системе обрабатывать больше 14 rps.
Capacity point – точка, где перестает расти пропускная способность и увеличивается время ответа.
Исходя из этого тестирования выбираются значения для stress, load и soak/endurance тестов. Для stress берется значение близкое к capacity point, но немного меньше. Для load количество пользователей из зоны деградации.
Важно, ваша цель - не получить кол-во rps, при котором все взрывается, а понять, какой именно ресурс станет узким местом при повышении нагрузки. Поэтому, если обстреливаемый вами сервер не покрыт мониторингом — можете даже не начинать тест. Общий подход к сбору телеметрии — чем больше метрик собирается, тем лучше. Начать стоит с минимального набора:
Источники:
Нагрузочное тестирование - это тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе. Этот подвид тестирования производительности выполняется для диагностики поведения системы при увеличении рабочей нагрузки.
Пример. Предположим, что требование нашего клиента для страницы входа составляет 2–5 секунд, и эти 2–5 секунд должны быть всегда, пока нагрузка не достигнет 5000 пользователей, а также если количество пользователей постепенно увеличивается, то сколько ЦП, памяти будет потребляться, каково состояние сети, время отклика, пропускная способность и т.д.
Подход к нагрузочному тестированию:
Устойчивое состояние обычно представляет собой одночасовое испытание под нагрузкой с нарастанием 15 минут и замедлением 15 минут.
Пример модели рабочей нагрузки: Предположим, что это интернет-магазин, где пользователи войдут в приложение и получат широкий выбор платьев для покупок и могут перемещаться по каждому продукту. Чтобы просмотреть подробную информацию о каждом продукте, им нужно щелкнуть по продукту. Если им нравится цена и качество продукта, они могут добавить его в корзину и купить продукт, выполнив проверку и произведя оплату. Список сценариев:
Business Flow | Количество транзакций | Виртуальная пользовательская нагрузка | Время отклика (сек) | % Допустимая частота отказов | Транзакций в час |
1 | 17 | 1600 | 3 | Менее 2% | 96000 |
2 | 17 | 200 | 3 | Менее 2% | 12000 |
3 | 18 | 120 | 3 | Менее 2% | 7200 |
4 | 20 | 80 | 3 | Менее 2% | 4800 |
Приведенные выше значения были получены на основе следующих расчетов: Транзакций в час = Количество пользователей * Транзакции, совершенные одним пользователем за один час. Количество пользователей = 1600. Общее количество транзакций в сценарии просмотра = 17. Время отклика для каждой транзакции = 3. Общее время, за которое один пользователь совершил 17 транзакций = 17 * 3 = 51, округленное до 60 секунд (1 мин). Транзакций в час = 1600 * 60 = 96000 Транзакций.
Источники:
Стрессовое тестирование выполняется самым первым, если нет отдельного Capacity тестирования, хотя по факту это все равно будет Capacity, т.к. нагрузка берется «с потолка». Стресс-тестирование - это отрицательное / негативное тестирование, которые проводят при больших нагрузках или нагрузках, выходящих за допустимые пределы, чтобы определить поведение системы при таких обстоятельствах, точку отказа системы (числовые показатели метрик), показываются ли корректные ошибки при этом и не теряются ли данные. Это тестирование также называют Fatigue testing.
Виды стресс-тестирования:
Подход / процесс содержит те же этапы, что описаны в нагрузочном, и то же самое в остальных подвидах, поэтому дублировать нет смысла.
Примеры:
Пиковое тестирование (Spike Testing) - это разновидность стресс-тестирования, проводится для проверки характеристик производительности, когда тестируемая система подвергается моделям рабочей нагрузки и объемам нагрузки, которые многократно увеличиваются за пределы ожидаемых производственных операций в течение коротких периодов времени. Обычно продолжительность теста составляет 1 час; он может отличаться в зависимости от вашего SLA / требований.
Источники:
Тестирование масштабируемости проводится для определения способности приложения масштабироваться с точки зрения пользовательской нагрузки, количества транзакций, объема данных и т. д. Цель теста масштабируемости отличается от стрессового или нагрузочного тестирования. Например, компания ожидает шестикратного увеличения нагрузки на серверы в течение следующих двух месяцев. Им может потребоваться увеличить производительность сервера и сократить время обработки запроса, чтобы лучше обслуживать посетителей. Если приложение масштабируемое, вы можете сократить это время, обновив оборудование сервера, например, вы можете увеличить частоту ЦП и добавить больше ОЗУ. Также вы можете улучшить производительность запросов, изменив программное обеспечение сервера, например, заменив хранилища данных в текстовых файлах базами данных SQL Server. Чтобы найти лучшее решение, вы можете сначала протестировать изменения оборудования, затем изменения программного обеспечения, а затем сравнить результаты тестов.
Пример: если тестирование масштабируемости определяет максимальную нагрузку в 10 000 пользователей, то для обеспечения масштабируемости системы разработчикам необходимо принять меры по таким факторам, как уменьшение времени отклика после достижения лимита в 10 000 пользователей или увеличение размера ОЗУ для соответствия растущему количеству пользовательских данных.
Источники:
Объемное тестирование (также flood testing) предназначено для прогнозирования того, может ли система / приложение обрабатывать большой объем данных в плане проверки объема данных, обрабатываемых базой данных. Это тестирование сосредоточено на наполнении БД продукта в реальных сценариях использования, отслеживании производительности приложения при различных объемах БД. Обычно продолжительность проверки объема составляет 1 час или время, необходимое для обработки n записей; оно может варьироваться в зависимости от вашего SLA / требований.
Причины для проведения этого тестирования:
Примеры тест-кейсов:
Источники:
Тестирование на выносливость (Endurance Testing, оно же Stability Testing, Soak Testing, Longevity Testing) включает в себя тестирование системы со значительной нагрузкой в течение длительного периода времени, чтобы выяснить, как система ведет себя при длительном использовании. То есть для обеспечения того, чтобы производительность и / или время отклика после некоторого длительного периода устойчивой активности были не хуже, чем в начале теста. В основном используется для проверки утечек памяти, времени отклика, правильности подключения и закрытия подключения к модулям (например, БД) и т.п. Обычно продолжительность испытания на выносливость составляет 6-8 часов; может отличаться в зависимости от вашего SLA / требований.
Источники:
Тестирование устойчивости направлено на обеспечение хорошей работы приложений в реальных или хаотичных условиях. Другими словами, оно проверяет отказоустойчивость приложения или способность противостоять стрессовым или сложным факторам, а также включает в себя тестирование на соответствие (compliance), выносливость (endurance), нагрузочное тестирование и тестирование восстановления (recovery testing). Эту форму тестирования иногда также называют chaos engineering. Поскольку отказов невозможно избежать, тестирование устойчивости гарантирует, что программное обеспечение может продолжать выполнять основные функции и избежать потери данных даже в критических условиях, например, при сбое сети, отказе базы данных, при необходимости выдавая соответствующие сообщения об ошибках. При тестировании на устойчивость запланированным результатом является надежность (Reliability). Устойчивость также известна как восстанавливаемость (recoverability). Тестирование устойчивости можно рассматривать как часть плана обеспечения непрерывности бизнеса (BCP - business continuity plan) организации.
Шаги:
Источник:
Доп.материал:
Надежность (Reliability) - это «вероятность безотказной работы программного обеспечения в течение определенного периода времени в определенной среде», т.е. это результат, к которому стремятся разработчики, способом достижения которого является устойчивость. Тестирование надежности связано с качеством программного обеспечения и стандартизацией продуктов. Если мы можем повторять тест-кейсы и постоянно получать один и тот же результат, то продукт считается «надежным». Тестирование надежности выполняется, чтобы убедиться, что программное обеспечение надежно, соответствует цели, для которой оно создано, и в течение определенного периода времени в данной среде способно обеспечить безотказную работу. Тестирование надежности может включать в себя Feature Testing, Security testing, Load Testing, Regression Testing и др.
Основные варианты для оценки надежности:
План тестирования надежности:
Имея правильную модель, мы можем предсказать качество продукта. К двум типам моделей относятся:
Источники:
Тестирование на отказ и восстановление (Failover and Recovery testing, Disaster Recovery Testing) - подвид тестирования производительности, проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками ПО, отказами оборудования или проблемами связи/сети. Failover - проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта. Методика подобного тестирования заключается в симулировании различных условий сбоя, последующем изучении и оценке реакции защитных систем. В процессе подобных проверок выясняется, была ли достигнута требуемая степень восстановления системы после возникновения сбоя. В отличие от тестирования надежности (Reliability Testing), которое проводится, чтобы найти отказ в конкретной точке, где он происходит, Recovery Testing проводится для проверки того, насколько хорошо система восстанавливается после сбоя или аварии.
Для наглядности рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие как:
Источник:
What Is Recovery Testing In Software Testing
Эталонное тестирование (Benchmark Testing) - это набор стандартов, метрик или контрольных точек (reference point), по которым оценивается (assessed or evaluated) качество работы продукта или услуги, через нагрузочное тестирование модуля или всей комплексной программной системы для определения ее производительности. Оно определяет повторяемый набор экспериментальных результатов, которые помогают определить функциональные возможности как для текущих, так и для будущих выпусков программного обеспечения.
Базовое тестирование (Baseline Testing) - это подход к тестированию, в котором за точку отсчета берется базовая линия - это показатель конкретного ориентира, который служит основой для нового тестирования. В Baseline Testing тесты прогоняют, сохраняют все результаты и сравнивают с базовым уровнем. Этот базовый уровень относится к последним принятым результатам испытаний. Если в исходном коде есть новые изменения, то для повторного выполнения тестов необходимо сформировать текущий базовый уровень. Если последние результаты будут приняты, то текущая базовая линия станет базовой. Определение из ISTQB/IEEE 610: базовая версия (baseline): Спецификация или программный продукт, который был формально отрецензирован или согласован, впоследствии используется как базовая версия для дальнейшей разработки, и который может быть изменен только в процессе формального контроля процесса изменений.
Самым первым этапом жизненного цикла разработки программного обеспечения является сбор и анализ требований. Этот тест играет важную роль, так как в случае, если начальная фаза не протестирована должным образом, в дальнейшем могут возникнуть серьезные проблемы. Это также может повлиять на стоимость, сроки, бюджет и репутацию клиента. После того, как требование собрано бизнес-аналитиком, он обсуждает то же самое с менеджером проекта для тестирования требования и его осуществимости. В случае неясности прототип требования создается разработчиком и представляется клиенту. Если это соответствует ожиданиям клиента и одобрено, командам предоставляется документ с требованиями для начала дальнейшего процесса. На основе этого документа с требованиями создаются другие документы для разработки и тестирования программного обеспечения, такие как план проекта, проектный документ, план тестирования, тестовые примеры и т. д. Поэтому очень важно правильно выполнить базовый тест. Если документ с требованиями не подтвержден должным образом, дальнейшие документы и процессы не пройдут. После завершения тестирования начинается процесс разработки и тестирования.
Разница между Baseline и Benchmark testing:
Benchmark testing | Baseline Testing |
Метрики уже созданы для оценки производительности приложения. Оно сравнивает характеристики продукта с отраслевыми стандартами; | Метрики создаются после завершения тестирования производительности. Набор тест-кейсов запускается для сбора информации о производительности; |
Проводится с точки зрения бизнеса. SLA создаются на основе того же; | Выполняется на самом начальном этапе, с которого начинаются разработка, внедрение, тестирование и сравнение; |
Можно пользоваться для всех продуктов / программного обеспечения в организации; | Проводится для конкретных продуктов / программного обеспечения; |
Это состояние, в котором вы хотите достичь или превзойти то, чего вы уже достигли; | Выполняется на самом начальном этапе, с которого начинаются разработка, внедрение, тестирование и сравнение; |
Предназначено для измерения производительности приложения вместе с другим приложением, имеющим аналогичные функции; | Определяет производительность приложения для сравнения в будущем; |
Пороговый тест (Threshold Test) - это тест, вставленный в Deployment Pipeline, который отслеживает некоторое измеримое явление, сравнивая значение в текущей сборке с пороговым значением. Если значение текущей сборки превышает пороговое значение, тест завершается неудачно, и сборка не выполняется. Типичный пример использования пороговых тестов - производительность. Команда берет репрезентативный набор операций и засекает их. Затем они устанавливают пороговый тест и если эти операции занимают значительное количество времени, превышающее текущее значение, тест завершается неудачей.
Источники:
Тестирование хранилища (Storage testing, Storage Performance testing) - это вид тестирования ПО, используемого для проверки того, как тестируемое ПО хранит данные в соответствующих каталогах и достаточно ли в них места для предотвращения неожиданного завершения работы из-за недостатка места на диске. ПО должно обрабатывать такие исключения и отображать предупреждающее сообщение для пользователя.
Зачем оно нужно?
Типы:
Источник:
Storage Testing Tutorial: What is, Type, Concepts
Доп. материал:
Concurrency testing - это подвид нагрузочного тестирования, при котором проверяется поведение системы (веб-приложение, веб-страница или API) в момент, когда одновременно происходят два или более событий, или выполняется одновременный вход нескольких пользователей в систему с выполнением одного и того же действия. Во время теста наблюдаются и записываются определенные метрики, а также измеряется время отклика системы в периоды устойчивой большой нагрузки. Зачем оно нужно:
Concurrency Testing Techniques: Reviewing code, Static Analysis, Con testing, Reachability Testing, Fuzz Testing, Random testing, Extending concolic testing.
Источники:
Качество обслуживания, предоставляемого веб-приложением, может быть определено включением всех его атрибутов, таких как функциональность, производительность, надежность, удобство использования, безопасность и так далее. Однако для наших целей здесь мы выделяем три конкретные задачи обслуживания (?service objectives), которые подвергаются тщательной проверке в рамках того, что мы называем «?тестированием услуг»:
Во всех трех случаях нам необходимо моделировать пользовательскую нагрузку для эффективного проведения тестов. Цели производительности, надежности и управляемости существуют в контексте реальных клиентов, использующих сайт для бизнеса. Скорость отклика (в данном случае время, необходимое одному системному узлу для ответа на запрос другого) сайта напрямую зависит от ресурсов, доступных в технической архитектуре. Чем больше клиентов используют эту услугу, тем меньше технических ресурсов доступно для обслуживания запросов каждого пользователя, и время отклика сокращается. Очевидно, что слабо загруженная служба с меньшей вероятностью выйдет из строя. Большая часть сложности программного и аппаратного обеспечения существует для удовлетворения требований к ресурсам в рамках технической архитектуры, когда сайт сильно загружен. Когда сайт загружен (или перегружен), конфликтующие запросы ресурсов должны управляться различными компонентами инфраструктуры, такими как серверные и сетевые операционные системы, системы управления базами данных, продукты веб-серверов, брокеры объектных запросов, промежуточное ПО и т. д. Эти компоненты инфраструктуры обычно более надежны, чем код специально созданного приложения, которому требуются ресурсы, но сбои могут произойти в одном из следующих случаев:
Моделируя типичные и необычные производственные нагрузки в течение длительного периода, тестировщики могут выявить недостатки в конструкции или реализации системы. Когда эти недостатки будут устранены, те же тесты продемонстрируют устойчивость системы. Для всех служб обычно существует ряд критических процессов управления, которые необходимо выполнить для обеспечения бесперебойной работы службы. Можно было бы закрыть службу для выполнения планового обслуживания в нерабочее время, но большинство онлайн-служб работают 24 часа в сутки. Рабочий день сервиса никогда не заканчивается. Неизбежно, что процедуры управления должны выполняться, пока служба работает и пользователи находятся в системе. Эти процедуры необходимо тестировать при наличии нагрузки на систему, чтобы убедиться, что они не оказывают отрицательного воздействия на живую службу, известную как тестирование производительности.
Тестирование управления услугами (Service Management Testing). Когда служба развертывается в производственной среде, ею необходимо управлять. Для поддержания работоспособности службы необходимо, чтобы ее отслеживали, обновляли, создавали резервные копии и быстро исправляли, когда что-то пойдет не так. Процедуры, которые менеджеры служб используют для выполнения обновлений, резервного копирования, выпусков и восстановлений после сбоев, критически важны для обеспечения надежной службы, поэтому им необходимо тестирование, особенно если служба претерпит быстрые изменения после развертывания. Необходимо решить следующие конкретные проблемы:
По возможности тесты должны проводиться реалистично.
Источник:
Leadership in test: service testing
Это тип тестирования ПО, который выявляет уязвимости, угрозы и риски. Целью тестов безопасности является выявление всех возможных лазеек и слабых мест в ПО, которые могут привести к потере информации, доходов, репутации компании, сотрудников или клиентов. Общая стратегия безопасности основывается на трех основных принципах:
Тестирование безопасности обычно выполняет отдельный специалист по безопасности. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:
При неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему. Задача проектировщика системы — сделать цену проникновения более высокой, чем цена получаемой в результате информации.
Типы тестирования безопасности:
SDLC фаза | Security Processes |
Requirements | Анализ безопасности для требований и проверка случаев злоупотребления / неправильного использования |
Design | Анализ рисков безопасности для проектирования. Разработка плана тестирования с учетом тестирования безопасности |
Coding and Unit testing | Статическое и динамическое тестирование безопасности и тестирование белого ящика |
Integration testing | Тестирование черного ящика |
System testing | Тестирование черного ящика и сканирование уязвимостей |
Implementation | Тестирование на проникновение, сканирование уязвимостей |
Support | Анализ воздействия патчей |
Тестирование безопасности может выполняться методом любого ящика, а также Tiger Box: этот взлом обычно выполняется на ноутбуке с набором операционных систем и инструментов для взлома. Это тестирование помогает тестерам на проникновение и тестерам безопасности проводить оценку уязвимостей и атаки.
Методы тестирования безопасности:
Доступ к приложению. Будь то настольное приложение или веб-сайт, безопасность доступа обеспечивается функцией «Управление ролями и правами». Часто это делается неявно при описании функциональности, Например, в системе управления больницей администратор меньше всего беспокоится о лабораторных исследованиях, поскольку его работа состоит в том, чтобы просто зарегистрировать пациентов и назначить их встречи с врачами. Таким образом, все меню, формы и экраны, относящиеся к лабораторным тестам, не будут доступны для роли «регистратора». Следовательно, правильная реализация ролей и прав гарантирует безопасность доступа.
Как протестировать доступ к приложению: Чтобы это проверить, необходимо выполнить тщательное тестирование всех ролей и прав. Тестировщик должен создать несколько учетных записей пользователей с разными, а также с несколькими ролями. Затем он должен использовать приложение с помощью этих учетных записей и убедиться, что каждая роль имеет доступ только к своим собственным модулям, экранам, формам и меню. Если тестировщик обнаруживает конфликт, он должен с полной уверенностью зарегистрировать проблему безопасности. Некоторые из тестов аутентификации включают в себя проверку правил качества пароля, проверку входа в систему по умолчанию, проверку восстановления пароля, проверку проверки подлинности, проверку функциональности выхода, проверку смены пароля, проверку контрольного вопроса / ответа и т. д. Аналогичным образом, некоторые из тестов авторизации включают в себя тест на обход пути, тест на отсутствие авторизации, тест на проблемы горизонтального контроля доступа и т. д.
Защита данных. Есть три аспекта безопасности данных. Во-первых, пользователь может просматривать или использовать только те данные, которые он должен использовать. Это также обеспечивается ролями и правами. Например, TSR (представитель по телефону) компании может просматривать данные об имеющихся запасах, но не может видеть, сколько сырья было закуплено для производства. Итак, этот аспект тестирования безопасности уже объяснен выше. Второй аспект защиты данных связан с тем, как эти данные хранятся в БД. Все конфиденциальные данные должны быть зашифрованы, чтобы сделать их безопасными. Шифрование должно быть надежным, особенно для конфиденциальных данных, таких как пароли учетных записей пользователей, номера кредитных карт или другой критически важной для бизнеса информации. Третий и последний аспект является продолжением этого второго аспекта. При передаче конфиденциальных или важных для бизнеса данных необходимо принять надлежащие меры безопасности. Независимо от того, перемещаются ли эти данные между разными модулями одного и того же приложения или передаются в разные приложения, они должны быть зашифрованы для обеспечения безопасности.
Как протестировать защиту данных: Тестировщик должен запросить в базе данных «пароли» учетной записи пользователя, информацию о выставлении счетов клиентов, другие важные для бизнеса и конфиденциальные данные и убедиться, что все такие данные хранятся в зашифрованной форме. Точно так же он должен убедиться, что данные передаются между различными формами или экранами только после надлежащего шифрования. Более того, тестировщик должен убедиться, что зашифрованные данные должным образом расшифрованы в месте назначения. Особое внимание следует уделить различным действиям «отправить». Тестировщик должен убедиться, что информация, передаваемая между клиентом и сервером, не отображается в адресной строке веб-браузера в понятном формате. Если какая-либо из этих проверок завершится неудачно, значит, в приложении определенно есть баги безопасности. Тестировщик также должен проверить правильность использования соления (salting - добавление дополнительного секретного значения к конечному вводу, например пароля, что делает его более надежным и трудным для взлома). Небезопасная случайность также должна быть проверена, поскольку это своего рода уязвимость. Другой способ проверить защиту данных - проверить использование слабого алгоритма. Например, поскольку HTTP - это протокол открытого текста, если конфиденциальные данные, такие как учетные данные пользователя, передаются через HTTP, то это угроза безопасности приложения. Вместо HTTP конфиденциальные данные следует передавать через HTTPS (защищенный через SSL, туннель TLS). Однако HTTPS увеличивает поверхность атаки, поэтому необходимо проверить правильность конфигурации сервера и гарантировать действительность сертификата;
Атака грубой силы (Brute-Force Attack, атака полным перебором) в основном выполняется некоторыми программными инструментами. Идея состоит в том, что, используя действительный идентификатор пользователя, программное обеспечение пытается подобрать связанный пароль, пытаясь войти в систему снова и снова. Простым примером защиты от такой атаки является приостановка учетной записи на короткий период времени, как это делают все почтовые приложения, такие как Yahoo, Gmail и Hotmail. Если определенное количество последовательных попыток (в основном 3) не позволяют войти в систему, эта учетная запись блокируется на некоторое время (от 30 минут до 24 часов).
Как протестировать атаку грубой силы: Тестировщик должен убедиться, что какой-то механизм блокировки учетной записи доступен и работает правильно. Он должен попытаться войти в систему с недопустимыми идентификаторами пользователя и паролями, в качестве альтернативы, чтобы убедиться, что программное обеспечение блокирует учетные записи, если предпринимаются постоянные попытки входа с недопустимыми учетными данными. Если приложение делает это, оно защищено от атаки методом перебора. В противном случае тестировщик должен сообщить об этой уязвимости системы безопасности. Тестирование перебором также можно разделить на две части - тестирование черного ящика и тестирование серого ящика. При тестировании «черного ящика» метод аутентификации, используемый приложением, обнаруживается и тестируется. Тестирование серого ящика основано на частичном знании пароля и данных учетной записи, а также на атаках компромисса памяти (подробнее).
Вышеупомянутые три аспекта безопасности следует учитывать как для веб-приложений, так и для настольных приложений, в то время как следующие моменты относятся только к веб-приложениям.
SQL-инъекции и XSS (межсайтовый скриптинг). С концептуальной точки зрения, темы обеих попыток взлома схожи, поэтому они обсуждаются вместе. В этом подходе вредоносный сценарий используется хакерами для манипулирования веб-сайтом. Есть несколько способов застраховаться от таких попыток. Для всех полей ввода веб-сайта длины полей должны быть достаточно малыми, чтобы ограничить ввод любого скрипта. Например, поле «Фамилия» должно иметь длину поля 30 вместо 255. Могут быть некоторые поля ввода, в которых требуется ввод больших данных, для таких полей необходимо выполнить правильную проверку ввода до сохранения этих данных в приложении. Более того, в таких полях должны быть запрещены любые HTML-теги или ввод тегов скрипта. Чтобы спровоцировать XSS-атаки, приложение должно отклонять перенаправления скриптов от неизвестных или ненадежных приложений.
Как тестировать SQL-инъекцию и XSS: Тестер должен убедиться, что максимальная длина всех полей ввода определена и реализована. Он также должен гарантировать, что заданная длина полей ввода не соответствует вводу сценария, а также вводу тега. Оба они могут быть легко протестированы. Например, если 20 - максимальная длина, указанная для поля «Имя», а входная строка «<p> thequickbrownfoxjumpsoverthelazydog» можно проверить оба этих ограничения. Тестировщик также должен убедиться, что приложение не поддерживает методы анонимного доступа. Если какая-либо из этих уязвимостей существует, приложение находится в опасности. В основном, тестирование SQL-инъекции может быть выполнено следующими пятью способами:
Точки доступа к сервису (закрытые и безопасные открытые).
Сегодня компании зависят друг от друга и сотрудничают друг с другом, то же самое относится и к приложениям, особенно к веб-сайтам. В таком случае оба участника должны определить и опубликовать несколько точек доступа друг для друга. Пока сценарий кажется довольно простым и понятным, но для некоторых веб-продуктов, таких как торговля акциями, все не так просто и легко. Когда существует большое количество целевой аудитории, точки доступа должны быть достаточно открытыми, чтобы облегчить работу всех пользователей, достаточно приспособленными для выполнения всех запросов пользователей и достаточно безопасными, чтобы справиться с любой опасностью.
Как протестировать точки доступа к сервису (Service Access Points): позвольте мне объяснить это на примере веб-приложения для торговли акциями; инвестор (желающий приобрести акции) должен иметь доступ к текущим и историческим данным о ценах на акции. Это требует, чтобы приложение было достаточно открытым. Под удобством и безопасностью я подразумеваю, что приложение должно облегчить инвесторам возможность свободно торговать (в соответствии с законом). Они могут покупать или продавать 24/7, и данные транзакций должны быть защищены от любых хакерских атак. Более того, большое количество пользователей будет взаимодействовать с приложением одновременно, поэтому приложение должно предоставлять достаточно точек доступа, чтобы удовлетворить всех пользователей. В некоторых случаях эти точки доступа могут быть закрыты для нежелательных приложений или людей. Это зависит от бизнес-домена приложения и его пользователей, например, настраиваемая веб-система управления офисом может распознавать своих пользователей на основе IP-адресов и отказывать в установлении соединения со всеми другими системами (приложениями), которые не попадают в диапазон допустимых IP-адресов для этого приложения. Тестировщик должен гарантировать, что весь межсетевой и внутрисетевой доступ к приложению осуществляется доверенными приложениями, машинами (IP) и пользователями. Чтобы убедиться, что открытая точка доступа достаточно безопасна, тестировщик должен попытаться получить к ней доступ с разных машин, имеющих как доверенные, так и ненадежные IP-адреса. Следует опробовать различные типы транзакций в реальном времени сразу, чтобы быть уверенным в производительности приложения. Таким образом, пропускная способность точек доступа приложения также будет четко отслеживаться. Тестировщик должен убедиться, что приложение обрабатывает все запросы связи от доверенных IP-адресов и приложений только тогда, когда все остальные запросы отклоняются. Точно так же, если в приложении есть открытая точка доступа, тестировщик должен убедиться, что она разрешает (при необходимости) загрузку данных пользователями безопасным способом. Под этим безопасным способом я имею в виду ограничение размера файла, ограничение типа файла и сканирование загруженного файла на вирусы или другие угрозы безопасности.
Управление сессией. Веб-сеанс - это последовательность транзакций HTTP-запроса и ответа, связанных с одним и тем же пользователем. Тесты управления сеансом проверяют, как управление сеансом обрабатывается в веб-приложении. Вы можете проверить истечение срока действия сеанса после определенного времени простоя, завершение сеанса после максимального времени жизни, завершение сеанса после выхода из системы, проверить объем и продолжительность сеанса cookie, проверить, может ли один пользователь иметь несколько одновременных сеансов и т. д.
Обработка ошибок. Тестирование на обработку ошибок включает:
Конкретные опасные функции. В основном, две рискованные функции - это платежи и загрузка файлов. Эти функции следует очень хорошо протестировать. Для загрузки файлов вам необходимо в первую очередь проверить, ограничена ли загрузка нежелательных или вредоносных файлов. Для платежей вам необходимо в первую очередь протестировать на наличие уязвимостей инъекций, небезопасного криптографического хранилища, переполнения буфера, подбора пароля и т. д.
Источники:
Доп. материал:
Уязвимость - это любые ошибки или недостатки в процедурах безопасности системы, разработке, реализации или любом внутреннем контроле, которые могут привести к нарушению политики безопасности системы.
Оценка уязвимости - это процесс оценки рисков безопасности в программной системе с целью уменьшения вероятности угрозы. Целью оценки уязвимости является снижение возможности несанкционированного доступа для злоумышленников (хакеров).
Анализ проникновения зависит от двух механизмов, а именно от оценки уязвимости и тестирования на проникновение (VAPT - Vulnerability Assessment and Penetration testing).
Классификация уязвимостей:
Наиболее распространенные уязвимости сетевой безопасности:
Способ устранения: мы можем остановить автоматическую установку их в ОС, изменив настройки по умолчанию в операционных системах, и можем сделать их более безопасными от вирусных атак с USB-накопителей.
Способ устранения: все конфиденциальные и важные данные должны храниться в зашифрованном виде, чтобы третьи лица не могли легко получить к ним доступ. Права доступа к базе данных должны быть ограничены. В дополнение к этому, должен быть включен только порт LAN, а все остальные порты должны быть отключены администратором.
Способ устранения: установите такие политики, которые могут контролировать автоматический запуск программ порта USB в вашей системе.
Способ устранения: руководство должно ввести такие политики и правила контроля активов, которые могут отслеживать и контролировать неправомерное использование данных.
Способ устранения: использование политик безопасности электронной почты и частая смена паролей системы через определенный промежуток времени - лучшее решение для этого.
Способ устранения: необходимо внедрить политики, которые могут контролировать доступ к устройству при входе в среду сетевой системы и выходе из нее.
Способ устранения: пароль, используемый для сетевой безопасности, должен быть надежным, как уникальная комбинация буквенно-цифровых символов и символов. Кроме того, нельзя использовать один и тот же пароль в течение длительного времени, необходимо регулярно менять системный пароль для получения лучших результатов.
Способ устранения: Регулярное обновление программного обеспечения межсетевого экрана и правильная реализация.
Этапы оценки уязвимости:
Процесс оценки уязвимости выступает в качестве входных данных для политики сетевой безопасности (network security policy).
Классификации сканеров уязвимостей:
По типу активов/ресурсов (assets):
По источнику:
По авторизованности:
Тестирование на проникновение (Penetration testing):
Это имитация атаки, в ходе которой компьютерная система, сеть или приложение проверяются на наличие слабых мест в системе безопасности. Эти тесты основаны на сочетании инструментов и методов, которые настоящие хакеры использовали бы для взлома. Это похоже на то, как банк нанимает кого-то, чтобы в роли грабителя попытаться проникнуть в их здание и получить доступ к хранилищу. Если «грабитель» добьется успеха и проникнет в банк или хранилище, банк получит ценную информацию о том, как им нужно усилить меры безопасности. Другие распространенные названия тестов на проникновение - это white hat attacks and ethical hacking. Данный вид тестирования выполняется как вручную, так и автоматически и может быть как Black Box, так и Grey и White. Ввиду необходимости наличия специфических знаний и опыта для выполнения этого вида тестирования привлекается отдельный специалист – пентестер.
Примеры кейсов тестирования на проникновение:
Отличия Vulnerability Assessment от Penetration testing
VAPT = Vulnerability Assessment + Penetration testing
Vulnerability Assessment | Penetration Testing |
Это метод поиска и измерения уязвимости системы | Находит уязвимости и использует их |
Конечным результатом является список уязвимостей, которые приоретизируются по их влиянию | Тест на проникновение более целенаправлен. Он помогает наметить путь, по которому злоумышленник проникнет в систему |
В основном автоматизированно | В основном вручную |
Быстрее | Дольше |
Дешевле | Дороже |
Направлено вширь | Направлено вглубь каждой уязвимости для достижения конкретных целей |
Выполняется в критически важных системах в реальном времени | Выполняется на некритичных системах |
Оценка уязвимости должна проводиться не реже одного раза в квартал, в основном после обновления оборудования или серьезных изменений в сети | Тестирование на проникновение следует проводить ежегодно после значительных изменений |
Подробно описывается, какие уязвимости существуют и что изменилось с момента последнего анализа | Эффективно идентифицирует информацию, которая была скомпрометирована |
Источники:
Доп. материал:
FUZZ testing (fuzzing) - это тип тестирования безопасности, который обнаруживает ошибки кодирования и лазейки в программном обеспечении, операционных системах или сетях. Фаззинг включает в себя ввод огромного количества случайных данных, называемых fuzz, в тестируемое программное обеспечение, чтобы заставить его дать сбой или прорвать его защиту. Фаззинг часто выявляет уязвимости, которые могут быть использованы с помощью SQL-инъекции, переполнения буфера, отказа в обслуживании (DOS) и XSS. Fuzz-тестирование выполняется с помощью фаззера - программы, которая автоматически вводит полуслучайные данные в программу и обнаруживает ошибки. Fuzz-тестирование обычно выполняется автоматически.
Обычно fuzzing обнаруживает наиболее серьезные ошибки или дефекты безопасности. Это очень экономически эффективный метод тестирования. Fuzzing - один из самых распространенных методов хакеров, используемых для обнаружения уязвимости системы (сюда относятся популярные SQL- или скриптовые инъекции). Примеры фаззеров:
Типы ошибок, обнаруживаемых Fuzz testing:
Источники:
Доп. материал:
Фаззинг тестирование веб-интерфейса. Расшифровка доклада
Данные виды принято относить к нефункциональным видам тестирования, однако если конкретно безопасность или производительность является основным функционалом приложения, а не его атрибутами, то можно отнести и к функциональным. Как пример я бы привел программу-шифровальщик флешки (можно обсудить в коммьюнити, накидают вариантов).
“<..> Есть функциональное требование: “Пользователь должен иметь возможность перевести деньги со своей карты на другую карту по номеру".
Это функциональное требование (ну, на самом деле это целая тонна требований, но обобщим их до одной user story).
Оно отвечает на вопрос "какие операции должен уметь выполнять сервис".
К этой функциональности может предъявляться еще куча требований - по безопасности, по скорости, по отказоустойчивости, и т.д. Они описывают то, КАК система должна работать, а не ЧТО она должна уметь.
Нефункциональные требования могут быть критичными, могут блокировать выпуск той или иной функциональности. Но это все еще свойство фичи, а не какая-то самостоятельная ее функция.
В то же время, есть, например, функциональные требования безопасности, типа "автоматически блокировать транзакции обладающие характеристиками А, Б, В".
Источник: azshoo
Взаимодействие (Interoperability) - это способность одной системы взаимодействовать с другой системой. Это взаимодействие между двумя разными системами или двумя разными приложениями вместе. Часто взаимодействие путают с интеграцией, совместимостью и портируемостью.
Interoperability = Inter + operable
Inter - означает «между собой», «друг между другом», «взаимно».
Operable - означает «способный выполнить поставленную задачу».
Пример №1: Возьмем пример бронирования вашего рейса. Считайте, что вам нужно поехать из Нью-Дели в Нью-Йорк. Сейчас у вас нет прямого рейса. Вы должны лететь из Нью-Дели в Лондон, а затем лететь стыковочным рейсом из Лондона в Нью-Йорк. Поскольку у вас есть некоторые ограничения по времени, вы бронируете свой рейс из Нью-Дели в Лондон на авиалинии «Jet Airways» и из Лондона в Нью-Йорк на «Virgin Atlantic». Это означает, что все данные о ваших пассажирах были переданы от Jet Airways до Virgin Atlantic. Итак, здесь Jet Airways и Virgin Atlantic, оба являются независимыми приложениями вместе, и при бронировании вашего рейса ваши данные о бронировании передаются от Jet Airways в Virgin Atlantic в полном объеме, без предварительного уведомления.
Пример №2. Аналогичным образом представьте себе систему управления больницей, где записи пациентов обмениваются между одним отделением и другим отделением. Итак, здесь можно связать отдел с приложением. Информация о пациенте передается из одного приложения в другое без предварительного уведомления.
Уровни Interoperability testing:
Как провести Interoperability testing?
Мы можем следовать колесу Деминга (Deming wheel или цикл PDCA), чтобы провести Interoperability testing:
Plan: планирование - это самый важный этап определения стратегии выполнения практически любых задач при разработке программного обеспечения. Прежде чем мы на самом деле спланируем определение процедуры выполнения IOT, необходимо понять каждое приложение или систему, развернутую в сети. Мы должны знать обо всех приложениях - их функциональность, поведение, вводимые данные и раскрываемые результаты вывода. Я также рекомендовал бы, чтобы каждое приложение было полностью функционально протестировано и было без дефектов, прежде чем готовить его к interoperability testing. Поэтому, когда вы планируете, не думайте только об одном или двух приложениях, думайте обо всех приложениях как о едином блоке. Планируя этот метод тестирования, вы должны смотреть с высоты птичьего полета. Излишне говорить - задокументируйте свой план. Мы можем использовать план тестирования и немного адаптировать его в соответствии с требованиями к документированию планирования IOT. После того, как ваш план тестирования составлен, переходите к определению условий тестирования (test conditions). Основное внимание при получении условий тестирования не должно ограничиваться отдельными приложениями; вместо этого он должен быть основан на потоке данных через все приложения. Условия должны быть спроектированы таким образом, чтобы проходились если не все, но большинство приложений в сети. После определения условий тестирования переходите к разработке или написанию сценария (в случае, если вы планируете автоматизировать) ваших тест-кейсов. Вы можете создать RTM (матрицу прослеживаемости требований), чтобы сопоставить ваши тест-кейсы с условиями тестирования и ваши условия тестирования с условиями / требованиями приемочного тестирования. Когда вы работаете в сети, также важно спланировать нефункциональное тестирование. Это может быть нигде не записано или не задокументировано, но обязательно для проверки нефункциональных аспектов системы в целом. Эти нефункциональные области будут включать производительность и безопасность. При необходимости вы можете составить отдельный план для функционального тестирования, тестирования производительности и тестирования безопасности; или создайте единый план и разные документы с условиями тестирования для каждого из этих типов тестирования;
Do: это промежуток времени, в течение которого вы прогоняете тест-кейсы. Соответственно планируйте свое время для выполнения функционального и нефункционального тестирования. Мы следуем циклу тестирования (testing cycle) на этом этапе выполнения кейсов, логируем дефекты, команда разработчиков их устраняет, после чего мы выполняем повторное тестирование и регрессионное тестирование системы в целом, и предоставляем отчет о результатах тестирования;
Check - это этап, на котором мы пересматриваем результаты наших тестов и пытаемся сопоставить их с RTM и проверить, выполнены ли все ожидаемые требования и все ли приложения пройдены. Мы проверяем, что данные передаются и обмениваются правильно и плавно между приложениями / системами. Нам также нужно будет убедиться, что данные, которые мы просматриваем, не изменяются. Также подумайте о том, чтобы сделать ретроспективу всего процесса interoperability testing. Определите области, которые хорошо сработали, те, которые не удались, и любые элементы действий, о которых необходимо позаботиться.
Act - действовать по ретроспективным элементам. Пункты, которые были определены как «good practices», продолжают выполняться, а для пунктов, над которыми можно было бы лучше поработать, определяются шаги по их исправлению. Имейте в виду одну вещь: области или шаги, которые не сработали, НЕ должны повторяться. В конце концов, мы должны учиться на своих ошибках, а не повторять их.
Совместимость (Compatibility, Coexistence) - это метод, с помощью которого проверяется совместимость 2 или более приложений в одной среде. MS Word и Калькулятор - это два разных приложения, и они показывают ожидаемое поведение независимо в одной и той же операционной системе. Итак, мы говорим, что эти 2 приложения совместимы друг с другом. Другой пример: если сайт Google.com совместим, он должен открываться во всех браузерах и операционных системах. Тестирование совместимости - это нефункциональное тестирование для обеспечения удовлетворенности клиентов. Оно предназначено для определения того, может ли программное обеспечение или продукт работать в различных браузерах, базах данных, оборудовании, операционной системе, мобильных устройствах и сетях. На приложение также может влиять различные версии, разрешения, скорости интернета, конфигурации и т. д. Следовательно, важно тестировать приложение всеми возможными способами, чтобы уменьшить сбои и избежать затруднений, связанных с утечкой ошибок (bug’s leakage). Тест на совместимость всегда должен выполняться в реальной среде, а не в виртуальной. Протестируйте совместимость приложения с различными браузерами и операционными системами, чтобы гарантировать 100% покрытие.
Типы тестирования совместимости:
Источники:
Конфигурационное тестирование (Configuration testing) — специальный вид тестирования, направленный на проверку работы ПО при различных аппаратных и программных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д.).
Configuration = performance + compatibility:
Уровни конфигурационного тестирования для клиент-серверных приложений (для некоторых типов приложений может быть актуален только один):
Prerequisites:
Уже на начальном этапе становится очевидно, что чем больше требований к работе приложения при различных конфигурациях рабочих станций, тем больше тестов нам необходимо будет провести. В связи с этим, рекомендуем, по возможности, автоматизировать этот процесс, так как именно при конфигурационном тестировании автоматизация реально помогает сэкономить время и ресурсы. Конечно же автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником.
Примечание: в ISTQB вообще не говорится о таком виде тестирования как конфигурационное:
“configuration testing: See portability testing.”
Тестирование переносимости (Portability testing) - это вид тестирования, который определяет легкость или сложность, с которой программный компонент или приложение могут быть перемещены из одной среды в другую. Результаты тестирования, полученные в результате тестирования переносимости, помогают выяснить, насколько легко программный компонент из одной среды можно использовать в другой среде. Термин «среда» относится к переходу от одной операционной системы к другой, от одного браузера к другому или от одной версии базы данных к другой версии базы данных. Измерение переносимости - это усилия, необходимые для перемещения программного компонента из одной среды в другую. Одна единица измерения переносимости - это стоимость адаптации программного обеспечения к новой среде по сравнению со стоимостью повторной разработки программного обеспечения. Переносимость может включать в себя Installability, Adaptability, Replaceability, Compatibility or Coexistence, Interoperability, Localization.
Portability vs. Compatibility:
Источники:
Compliance - официальное соответствие ПО различным стандартам, законам, сертификация и т.п.
Conformance - неофициальные, внутренние стандарты организации, добровольное обязательство делать что-либо признанным образом, либо стремление к Compliance, но которое не закончено / не подтверждено формально.
Источник:
Тестирование удобства пользования - это нефункциональный вид тестирования программного обеспечения, являющийся подмножеством тестирования пользовательского опыта - UX, “Ю-Экс”, user experience. В целом оно подразделяется на понятность, обучаемость, работоспособность, привлекательность и соответствие (understandability, learnability, operability, attractiveness, and compliance). Юзабилити-тестирование предназначено для определения того, насколько программный продукт понятен, легок в освоении, прост в эксплуатации и привлекателен для пользователей при определенных условиях и требованиях. Этот тип тестирования обычно выполняется реальными пользователями.
Категории юзабилити-тестирования:
Методы юзабилити-тестирования:
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке - тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода, и как следствие улучшить качество продукта в целом.
Отсюда становится очевидно, что тестирование удобства пользования может производиться на разных уровнях разработки ПО: модульном, интеграционном, системном и приемочном.
Источники:
Доп. материал:
Тестирование доступности (accessibility testing) - это подмножество юзабилити-тестирования. Его цель - убедиться в том, что наш продукт удобен в использовании людям с различными видами ограничений, инвалидности или особенностями восприятия. Это могут быть проблемы со зрением, слухом или ограничения в подвижности рук. Что наиболее важно, существуют определенные законы и инструкции по тестированию доступности, которые также должны соблюдаться, например, Рекомендации по доступности веб-контента (Web content accessibility guidelines). Ваш продукт должен правильно работать с соответствующим ПО. Примеры такого программного обеспечения:
Еще один из примеров - люди с цветовой слепотой (дальтонизмом). Эта особенность довольно широко распространена. Различными видами цветовой слепоты страдают около 8 % мужчин и 0,4 % женщин - не так уж мало!
Цвет не должен быть единственным способом передачи информации. Если вы используете цвет для того, чтобы, допустим, отобразить статус, эту информацию стоит продублировать еще каким-то образом - геометрическими фигурами, иконками или текстовым комментарием.
Хорошая контрастность. Хорошая контрастность обеспечивает нормальную видимость элементов управления и текста даже для людей, не различающих те или иные оттенки.
Есть отличный инструмент для тестирования веб-сайтов на предмет доступности для людей с различными формами цветовой слепоты: Color Blind Web Page Filter.
Если вы хотите сократить количество тестов, можно ограничиться только тремя фильтрами: дейтеранопия, протанопия и тританопия. Это наиболее выраженные формы цветовой слепоты (не считая крайне редкого черно-белого зрения). Остальные люди с особенностями цветовосприятия видят больше оттенков, и если ваш UI достаточно хорошо виден с этими тремя фильтрами, то и для остальных будет отображаться корректно.
Пример чек-листа:
Источники:
Доп. материал:
Тестирование инсталляции (установки) направлено на проверку успешной установки, настройки, обновления и удаления ПО, как десктопного, так и мобильного.
Примеры кейсов:
Установка.
Обновление:
Откат до предыдущей версии:
Удаление приложения:
Источник:
Глобализированное ПО - это ПО, функционирующее одинаково качественно независимо от географической, культурной и национальной среды. Тестирование глобализации концентрируется на выявлении потенциальных проблем в дизайне продукта, которые могут испортить глобализацию. Например, разработчик должен заложить в CSS основу для вертикального текста, если в будущем планируется локализовать продукт на язык с вертикальным письмом, обработку почтовых индексов для разных стран (где-то цифры, где-то цифры с буквами и т.п.). Оно гарантирует, что код может обрабатывать желаемую международную поддержку без нарушения какой-либо функциональности. А также, что не будет никакой потери данных и проблем с отображением.
Globalization = Internationalization + Localization.
Интернационализация ПО (Internationalization (I18N)) – это особый процесс, при котором веб-софт создается таким образом, чтобы оно было равноудаленным от какой-либо культуры и (или) специфики определенного географического региона. Например, одна из задач по интернационализации ПО – корректное редактирование логики всех подключенных параметров форматирования (формат даты, времени, цифровое и валютное форматирование). Также, тестировщики во время проверки на соответствие ПО требованиям I18N тестируют работу продукта на одинаковую работу в разных регионах и культурах мира. Основной задачей тестирования интернациональности является проверка того, может ли программный код работать со всей международной поддержкой без нарушения функциональности, что может привести к потере данных или проблемам целостности информации. В основном, фокус тестирования интернационализации направлен на:
Локализация ПО (Localization (L10N)) – деятельность по модификации ПО в соответствии с определенными региональными настройками (языком, географической территорией, культурными особенностями). В данный вид проверки входит необходимость выполнения работ по переводу всего контента программного обеспечения для конечного пользователя. Во время перевода должны учитываться иконки, информационная графика, справочные материалы, техническая документация и иные культурные особенности регионов (например, онлайн-сервис по заказу бургеров не будет показывать корову на главной странице в Индии или свинью в мусульманских странах). На что обратить внимание:
Примеры проверок:
Примечание автора: частный случай задачи на тестирование локализации в android/ios приложениях может быть и в контексте файлов strings, в которых приложение хранит все текстовые строки. Строки могут быть с динамически подставляемыми параметрами чтобы содержимое строки динамически изменялось в зависимости от чего-либо. Например: “Вы сможете запросить код повторно через %s” или “Закрыто. До открытия %1$d ч.”, В данном случае потребуется проверить переводы на предмет того, что динамические аргументы в строках не были сломаны переводчиками. Лично я для этого писал скрипт на python, он есть в другом репозитории.
Источник:
What Is Globalization Testing (A Complete Guide)
Доп. материал:
Исследовательское Тестирование — одновременно является и техникой, и видом тестирования. В общем виде мы так или иначе всегда используем комбинацию сценарного и исследовательского подходов. Exploratory testing подразумевает под собой одновременно изучение проекта, функционала, тест-дизайн в уме и тут же исполнение тестов, после чего данный цикл может повторяться необходимое количество раз, каждый раз улучшая создаваемые кейсы и документируя пройденные сессии.
Джеймс Бах указал на важную характеристику исследовательского тестирования - тестировщик участвует когнитивно. Он активно, целенаправленно, с любопытством исследует тестируемое программное обеспечение, всегда принимая на себя ответственность каждую минуту решать, какой путь к тому, что он выбрала для исследования, является наиболее многообещающим. Нет никаких искусственных ограничений на разведку. Тестировщик может свободно использовать любые доступные источники информации, включая спецификации, записи службы технической поддержки, реализации сопоставимого программного обеспечения конкурентами и (конечно) эксперименты (тесты), которые эмпирически раскрывают информацию. Нет никаких ограничений на методы тестирования, которые могут использовать исследователи - например, любая степень автоматизации подойдет. Однако исследователь не просто перезапускает старые тесты, а тестирует чтобы учиться. Вероятно, он будет внимательно изучать поведение программы во время ее тестирования, ища новые идеи о том, как она может выйти из строя, как ее можно было бы в дальнейшем протестировать или измерить, и насколько полезны эти тесты на данном этапе разработки. Выполнение тестов можно автоматизировать, а мышление - нет. Антитезой исследования является тестирование по сценарию, в котором тестировщик (или машина) следует набору процедур, изложенных давно, сравнивая наблюдаемое поведение с любыми результатами, которые разработчик тестов считал актуальными или интересными в то время. Познание произошло тогда, а не сейчас. Объем исследования такой же, как и объем самого тестирования. Разница в том, что исследователь выполняет их в любой полезной последовательности, смешивая исследование, дизайн, выполнение, интерпретацию и общение, чтобы постоянно открывать новую информацию и идти в ногу с текущими изменениями на рынке, платформе, дизайне и реализации тестируемого программного обеспечения.
Подход к тестированию:
Туры в исследовательском тестировании: Чтобы систематизировать исследовательское тестирование можно использовать идею туров. Туры – это идеи и инструкции по исследованию программного продукта, объединенные определенной общей темой или целью. Туры, как правило, ограничены по времени – длительность тестовой сессии не должна превышать 4 часа. Идею туров развивали в своих работах Канер, Бах, Хендриксон, Болтон, Кохл и другие. Джеймс Виттакер (James A. Whittaker), хоть и не придумал саму идею туров, но предложил свой подход к исследовательскому тестированию с использованием туров и в своей книге “Exploratory Software Testing” в доступной форме озвучил идею туров и описал сами туры.
Тур – это своего рода план тестирования, он отражает основные цели и задачи, на которых будет сконцентрировано внимание тестировщика во время сессии исследовательского тестирования. При этом Виттакер использует метафору, что тестировщик – это турист, а тестируемое приложение – это город. Обычно у туриста (тестировщика) мало времени, поэтому он выполняет конкретную задачу в рамках выбранного тура, ни на что другое не отвлекаясь. Город (ПО) разбит на районы: деловой центр, исторический район, район развлечений, туристический район, район отелей, неблагополучный район.
Источники:
Доп. материал:
Свободное тестирование (ad-hoc testing) – это вид тестирования, который выполняется без подготовки к тестированию продукта, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Оно не требует никакой документации, планирования, процессов, которых следует придерживаться при выполнении тестирования. Такой способ тестирования в большинстве случаев дает большее количество заведенных отчетов об ошибке. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основной функциональной части продукта и выполняет как позитивные, так и негативные варианты возможных сценариев.
Чаще всего такое тестирование выполняется, когда владелец продукта не обладает конкретными целями, проектной документацией и ранее поставленными задачами. При этом тестировщик полагается на свое общее представление о продукте, сравнение с похожими продуктами, собственный опыт. Однако при тестировании ad-hoc тестировщик должен иметь полные знания и осведомленность о тестируемой системе, особенно если проект очень сложный и большой. Поэтому нужно хорошее представление о целях проекта, его назначении, основных функциях и возможностях.
Виды свободного тестирования (ad-hoc testing):
Основные преимущества ad-hoc testing:
Adhoc Testing | Exploratory Testing |
Начинается с изучения приложения, а затем - с фактического процесса тестирования | Начинается с тестирования приложения, а затем его понимания посредством исследования |
Самостоятельный вид тестирования | Разновидность Adhoc Testing |
Не требуется никакой документации | Обязательно наличие документации по деталям тестирования. |
Adhoc Testing проводят тестировщики, обладающие глубокими знаниями о приложении | Для изучения приложения не обязательно иметь эксперта. |
Тестирование начинается после того, как будут собраны все данные для проведения тестирования | Сбор данных и тестирование происходят одновременно. |
Это работает для отрицательных сценариев тестирования | В основном это касается положительных сценариев |
Ориентировано на улучшение процесса тестирования | Ориентировано на изучение приложения |
Зависит от творческих способностей и интуиции тестировщика | Зависит от любопытства и понимания тестировщика |
Нет ограничений по времени | Это ограниченный по времени метод |
Источники:
Maintenance является последней стадией SDLC. По мнению многих экспертов, по мере того, как изменения после релиза вносятся в существующее приложение, каждое изменение может рассматриваться как начало нового цикла SDLC, но точнее будет сказать, что проект в это время находится в жизненном цикле обслуживания программного обеспечения (SMLC - Software Maintenance Life Cycle). Многие проекты проводят большую часть своего времени именно в SMLC после релиза, а не в SDLC перед ним.
Maintenance testing (тестирование поддержки/обслуживания/эксплуатации/сопровождения) - это модификация программного продукта после его выпуска с целью исправления дефектов, улучшения производительности или других характеристик или для адаптации продукта к изменившемуся окружению. [IEEE 1219]. После того, как программное обеспечение или приложение задеплоены, оно начинает эксплуатироваться годами и даже десятилетиями. В это время система и ее операционная среда часто исправляются, изменяются или расширяются. Пользователю могут потребоваться некоторые добавленные или новые функции в текущем программном обеспечении, которые требуют внесения изменений в текущее программное обеспечение, и эти изменения должны быть протестированы. Конечным пользователям может потребоваться миграция программного обеспечения на другую самую последнюю аппаратную платформу или изменение среды, например версии ОС, варианта базы данных и т. д., что требует тестирования всего приложения на новых платформах и в новой среде. После того, как продукт релизится, он время от времени требует некоторого обслуживания в целях профилактики сбоев.
Основные активности (principal activities):
Задача выполнения Maintenance testing становится более эффективной, когда программное обеспечение имеет хорошую характеристику обслуживаемости (maintainability).
Reliability, maintainability в ISO 9126 определяется как «легкость, с которой программный продукт может быть изменен для исправления дефектов, модифицирован для соответствия новым требованиям, модифицирован для облегчения будущего обслуживания или адаптирован к изменившейся среде».
Maintainability состоит из:
Причины плохой Maintainability:
Основные риски (Maintainability Risks) | Последствия |
Усилия, необходимые для исправления дефектов и внесения изменений, могут быть больше, чем планировалось | Если размер группы поддержки (maintenance team), выполняющей эти задачи, будет фиксированным (обычная ситуация), это также приведет к увеличению временных затрат |
Время, затрачиваемое на задачи обслуживания, превышает фиксированные окна обслуживания (maintenance windows) | Это может отрицательно сказаться на производстве (например, сотрудники, прибывающие на работу, обнаруживают, что сервер приложений недоступен из-за проскальзывания окна планового ночного обслуживания) |
Поддержка (Maintainers) могут быть вынуждены сокращать сроки, чтобы не выходить за рамки согласованных периодов обслуживания. Им может потребоваться сделать предположения относительно реализации необходимых изменений (возможно, из-за плохой документации) | |
Если применяются Соглашения об уровне обслуживания, могут налагаться штрафы | |
Долгосрочное накопление плохой поддерживаемости в результате кумулятивного эффекта плохой практики разработки программного обеспечения | Уровень надежности постепенно снижается |
Увеличивается количество функциональных дефектов, вносимых изменениями (регрессии) | |
На исправление дефектов уходит больше времени | |
На персонал поддержки оказывается все большее давление, что может даже привести к дальнейшему ухудшению ситуации |
Виды Maintenance testing:
Для поддерживающего релиза (maintenance release) может потребоваться поддерживающее тестирование на нескольких уровнях тестирования с использованием различных типов тестов в зависимости от его объема. Объем технического обслуживания зависит от:
Триггеры для Maintenance. Существует несколько причин, по которым проводится обслуживание программного обеспечения, а значит, и тестирование обслуживания, как для запланированных, так и для незапланированных изменений. Мы можем классифицировать триггеры для обслуживания следующим образом:
Например, для систем Интернета вещей (IoT) тестирование обслуживания может быть инициировано введением в общую систему совершенно новых или модифицированных вещей, таких как аппаратные устройства и программные услуги. При тестировании обслуживания таких систем особое внимание уделяется интеграционному тестированию на разных уровнях (например, уровень сети, уровень приложений) и аспектам безопасности, в частности, тем, которые относятся к персональным данным.
Impact Analysis для Maintenance. Анализ воздействия оценивает изменения, которые были внесены в поддерживающую версию, чтобы определить предполагаемые последствия, а также ожидаемые и возможные побочные эффекты (side effects) изменения, а также определить области в системе, на которые это изменение повлияет. Анализ влияния также может помочь определить влияние изменения на существующие тесты. Побочные эффекты и затронутые области в системе необходимо протестировать на предмет регрессии, возможно, после обновления любых существующих тестов, затронутых изменением. Анализ воздействия может быть проведен до внесения изменения, чтобы помочь решить, следует ли вносить изменение, исходя из возможных последствий в других областях системы.
Источники:
Доп. материал:
Регресс - это противоположность прогресса. Любое ПО по мере прогресса в функционале неизбежно усложняется, увеличиваются взаимосвязи в функциях и т.п., и чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование. И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения. Но этого недостаточно. По-сути, проблема намного серьезнее - мы каждый раз не знаем, что принесет с собой новая функциональность в системе. Нам каждый раз надо предположить/узнать/протестировать новые взаимодействия в системе, а не тестировать только новые функции в изоляции от остальных. Старый функционал с новым если начинают пересекаться - надо заново расчехлять аналитику, выявлять новые ситуации, которые могут возникнуть, писать новые тест-кейсы, которые затрагивают уже не столько функциональные, сколько интеграционные аспекты. Поэтому выяснение "не наступил ли регресс" (внимание, не путать с "не наступила ли регрессия") - постоянная задача, которую также необходимо решать в контексте maintenance testing.
Регрессионное тестирование (Regression Testing) - собирательное название для всех видов тестирования программного обеспечения связанных с изменениями, направленных на обнаружение ошибок в уже протестированных участках исходного кода, на проверку того, что новая функциональность не зааффектила (affect) старую. Такие ошибки — когда после внесения изменений в программу перестаёт работать то, что должно было продолжать работать, — называют регрессионными ошибками (regression bugs). Регрессионные тесты должны быть частью релизного цикла (Release Cycle) и учитываться при тестовой оценке (test estimation).
При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках maintenance testing, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям. Регрессионное тестирование обычно проводится перед релизом новой версии приложения. Это происходит следующим образом: в течение какого-то времени делаются какие-то фичи и другие задачи, они тестируются по отдельности и сливаются в общую ветку (мастер/девелоп - чаще всего эта ветка называется в зависимости от процессов в проекте). Дальше, когда время подходит к релизу от ветки девелопа создается ветка релиза, из которой собирается релиз-кандидат и на нем уже проводят регресс.
Главной задачей maintenance testing является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям.
Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться. Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
Можно заключить, что регрессионное тестирование выполняется чтобы минимизировать регрессионные риски. То есть, риски того, что при очередном изменении продукт перестанет выполнять свои функции. С регрессионным тестированием плотно связана другая активность - импакт анализ (Impact Analysis, анализ влияния изменений). Итоговая область регрессии называется Regression Scope / Scope of Regression.
Классификация регрессионного тестирования:
Типы регрессии по Канеру:
Регрессия в Agile:
В Agile продукт разрабатывается в рамках короткой итерации, называемой спринтом, которая длится 2–4 недели. В Agile существует несколько итераций, поэтому это тестирование играет важную роль, поскольку в итерациях добавляется новая функциональность или изменения кода. Набор регрессионных тестов должен быть подготовлен на начальном этапе и обновляться с каждым спринтом. В Agile проверки регрессии делятся на две категории:
Смоук тестирование (Smoke testing)
Smoke testing, BVT - Build Verification Testing, BAT - Builds Acceptance Testing, Breath Testing, Shakeout/Shakedown Testing, Intake test, а также в русскоязычных вариантах дымовое, на дым, дымное, тестирование сборки и т.п. - это подмножество регрессионного тестирования, короткий цикл тестов, выполняемый для каждой новой сборки для подтверждения того, что ПО после внесенных изменений стартует и выполняет основные функции без критических и блокирующих дефектов. В случае отсутствия таковых дефектов Smoke testing объявляется пройденным, и команда QA может начинать дальнейшее тестирование полного цикла, в противном случае, сборка объявляется дефектной, что делает дальнейшее тестирование пустой тратой времени и ресурсов. В таком случае сборка возвращается на доработку и исправление. Smoke testing обычно используется для Integration, Acceptance and System Testing.
Если мы говорим про сайт интернет-магазина, то сценарий может быть следующим:
Если мы говорим про мобильное приложение, например, messenger, то:
Небольшая шпаргалка по степени важности:
Примечание. В русском языке термин ошибочно переводят как проверка дыма, корректнее уж говорить “на дым”. История термина: Первое свое применение этот термин получил у печников, которые, собрав печь, закрывали все заглушки, затапливали ее и смотрели, чтобы дым шел только из положенных мест. Повторное «рождение» термина произошло в радиоэлектронике. Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме. Если первое включение не выявило перегрева, то прибор включается снова на большее время. Проверка повторяется. И так далее несколько раз. Выражение «smoke-test» используется инженерами в шуточном смысле, так как появления дыма, а значит и порчи частей устройства, стараются избежать.
Санити тестирование (Sanity testing)
Sanity testing также является подмножеством регрессионного тестирования и выполняется до или вместо полной регрессии, но после smoke. Эти два подвида похожи (где-то вообще не заморачиваются и используют как синонимы), но в целом Sanity используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений.
Примечание. Санитарным это тестирование в русскоязычной среде назвалось по совершенно непонятным причинам, но гуглится только так. На самом же деле дословно переводится как тестирование на вменяемость / разумность / работоспособность / согласованность или по версии ISTQB “Тест работоспособности”.
Подтверждающее, повторное тестирование (confirmation testing, re-testing)
Повторное тестирование - это тип тестирования, выполняемый в новой сборке по проваленному на старой сборке тест-кейсу с тем же окружением и данными, для проверки того, что этот дефект теперь устранен. Ре-тест выполняется перед sanity-тестированием, приоритет ре-теста выше регрессионных проверок, поэтому оно должно выполняться перед ними.
Тестирование N+1 (N+1 testing)
Вариант регрессионного тестирования представлен как N+1. В этом методе тестирование выполняется в несколько циклов, в которых ошибки, обнаруженные в тестовом цикле «N», устраняются и повторно тестируются в тестовом цикле N + 1. Цикл повторяется, пока не будет найдено ни одной ошибки.
Разница между повторным и регрессионным тестированием:
Источники:
Дополнительный материал:
Frontend testing - это тип тестирования, который проверяет уровень представления (Presentation layer) в 3-уровневой архитектуре (3 Tier Architecture). С точки зрения непрофессионала, вы проверяете GUI - все, что видно на экране, на стороне клиента. Для веб-приложения интерфейсное тестирование будет включать проверку функциональных возможностей, таких как формы, графики, меню, отчеты и т. д., а также связанный Javascript. Frontend testing - это термин, охватывающий различные стратегии тестирования, включая оценку производительности фронтенда, которая является хорошей практикой перед тестированием приложения с высокими пользовательскими нагрузками. Тестировщик должен хорошо понимать бизнес-требования для выполнения этого типа тестирования. Ранее оптимизация производительности означала оптимизацию на стороне сервера. Это было связано с тем, что большинство веб-сайтов были в основном статичными, а большая часть обработки выполнялась на стороне сервера. Однако сегодня веб-приложения становятся более динамичными и в результате код на стороне клиента нередко становится причиной низкой производительности.
Тестирование клиентской части невозможно в некоторых случаях: бэкенд разрабатывают быстрее, чем фронтенд; очевидно, если клиентская часть отсутствует в принципе ( самодостаточное приложение, терминальная команда).
Backend testing - это тип тестирования, который проверяет уровень приложений и базы данных 3-уровневой архитектуры. В сложном программном приложении, таком как ERP, внутреннее тестирование повлечет за собой проверку бизнес-логики на уровне приложений. Для более простых приложений бэкэнд-тестирование проверяет серверную часть или базу данных. Это означает, что данные, введенные в интерфейс, будут проверены в базе данных. Базы данных проверяются на наличие свойств ACID, операций CRUD, их схемы, соответствия бизнес-правилам. Базы данных также проверяются на безопасность и производительность. Производится проверка целостности данных, Проверка достоверности данных, Тестирование функций, процедур и триггеров. При внутреннем тестировании нет необходимости использовать графический интерфейс. Вы можете напрямую передавать данные с помощью браузера с параметрами, необходимыми для функции, чтобы получить ответ в некотором формате по умолчанию. Например, XML или JSON. Вы также подключаетесь к базе данных напрямую и проверяете данные с помощью SQL-запросов.
Источник:
Frontend Testing Vs. Backend Testing: What’s the Difference?
Интерфейс - это то, с помощью чего происходит “общение” между ПО и окружением. Существует два типа интерфейсов:
Тестирование графического интерфейса пользователя (GUI) проводят с целью проверить функциональность и корректность отображения интерфейса пользователя (меню, панели инструментов, цвета, шрифты, размеры, значки, контент, кнопки и т. д., как они реагируют на ввод пользователя).
Техники тестирования GUI:
Некоторые методы моделирования, на основе которых могут быть получены тестовые примеры:
Тестирование на основе моделей - это развивающийся метод создания тестовых примеров на основе требований. Его главное преимущество по сравнению с двумя вышеупомянутыми методами заключается в том, что он может определять нежелательные состояния, которых может достичь ваш графический интерфейс.
Примеры проверок:
Источники:
Доп. материал:
Каждый день используя любимые мобильные приложения и веб-ресурсы вы незаметно взаимодействуете с API, скрытым под интерфейсом пользователя.
API действует как интерфейс между двумя программными приложениями и позволяет им связываться друг с другом на оговоренных правилах и не залезая в реализацию предоставляемых функций, при том правила - не договоренность, а контракт. Простой пример: вы можете встроить на свою главную страницу сайта маленький виджет прогноза погоды, который будет отправлять определенный правилами запрос к API некоего сервиса погоды и получать определенный правилами ответ, содержащий посылку с данными.
Еще более простой пример: примите официанта в качестве API ресторана. В ресторане вы даете заказ на основе блюд, определенных в меню. Официант принимает ваш заказ и на этом ваше участие заканчивается и вам не интересно, что там произойдет дальше. От официанта вы ожидаете только итог – вам приносят заказанное блюдо.
Можете попробовать взаимодействие с API сами: отправляете GET запрос на https://reqres.in/api/users, и получаете в ответ список пользователей. Это очень удобно, когда вы хотите предоставить интерфейс взаимодействия со своим сервисом сторонним лицам. Например, у google, instagram, vk и, в общем-то, всех популярных продуктов есть открытая часть API. То есть у вас есть документ с перечнем того, что и как можно спросить и что вам на это придет в ответ. Взаимодействовать с API можно и с веб-страницы, и с помощью специальных инструментов и напрямую из кода.
Тестирование API - это тип тестирования (хотя правильнее наверное сказать не тип или вид, а еще один вариант взаимодействия с системой) который включает в себя тестирование API напрямую, а также в рамках интеграционного тестирования, чтобы проверить, соответствует ли API ожиданиям с точки зрения функциональности, надежности, производительности и безопасности приложения. В тестировании API наш основной упор будет сделан на уровне бизнес-логики архитектуры программного обеспечения.
Типы тестирования API:
Примеры проблем, которые обнаруживает тестирование API:
Контрактное тестирование API
В общем случае контрактное тестирование или Consumer Driven Contract (CDC) является связующим звеном между модульным и интеграционным тестированием.
Каждый интерфейс имеет поставщика (supplier) и потребителя (consumer). Само собой, сервисы поставщика и потребителя распределены между разными командами, мы оказываемся в ситуации, когда четко прописанный интерфейс между ними (или контракт) просто необходим. Обычно многие подходят к этой проблеме следующим образом:
Сегодня многие компании заменили последние два шага на автоматизированные контрактные тесты, которые регулярно проверяют соответствие описания и реализации у поставщика и потребителя определенного контракта. Что является набором регрессионных тестов, которые обеспечивают раннее обнаружение отклонения от контракта.
Разберемся во взаимодействии на примере REST архитектуры: поставщик создает API c некоторым endpoint, а потребитель отправляет запрос к API, например, с целью получения данных или выполнения изменений в другом приложении. Это контракт, который описывается с помощью DSL (domain-specific language). Он включает API описание в форме сценариев взаимодействия между потребителем и поставщиком. С помощью CDC выполняется тестирование клиента и API с использованием заглушек, которые собираются на основе контракта. Основной задачей CDC является сближение восприятия между командами разработчиков API и разработчиков клиента. Таким образом, участники команды потребителей пишут CDC тесты (для всех данных проекта разработки), чтобы команда поставщика смогла запустить тесты и проверить API. В итоге команда поставщика с легкостью разработает свой API, используя тесты CDC. Результатом прогона контрактных тестов является понимание, что поставщик уверен в исправной работе API у потребителя. Следует обратить внимание, что команда потребителя должна регулярно осуществлять поддержку CDC-тестов при каждом изменении, и вовремя передавать всю информацию команде поставщика. Если регулярно фиксируем неудачно выполненные CDC-тесты, то следует пойти (в буквальном смысле слова, к пострадавшей стороне теста и узнать, в рамках какой задачи были изменения (что привело к падению теста).
Из того, что было описано выше, можно выделить следующие тезисы для выполнения контрактного тестирования:
Минусы CDC:
Отличие API от SDK:
SDK (software development kit) - это набор функционала (библиотек) и утилит для разработки. Собственно SDK и предоставляет реализацию некоторого API, это оболочка API's, которая упрощает работу для разработчиков.
Тестирование API без документации/черным ящиком:
Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определитесь, насколько все плохо и какая у Вас есть информация об объекте тестирования. Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints? Если дело совсем плохо - просканируйте порты, например, с помощью netcat. Открытые порты сохраните в файл. Эта операция займет довольно много времени. Можете почитать советы по работе с Nmap и Netcat. Если Вам известен нужный порт и соответствующий endpoint - переберите все возможные HTTP методы. Начните с наиболее очевидных POST, PUT, GET. Для ускорения процесса напишите скрипт, например, на Python.В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придется перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.
Разработчики обычно не особо заморачиваются и закладывают минимально-необходимую информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты. Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
Источники:
Доп. материал:
Для проведения A/B Testing (split testing,bucket testing) мы создаем и анализируем два варианта чего-либо (экрана приложения, страницы сайта, элементов GUI, механики работы, воронки продаж и т.п.), чтобы найти, какой вариант работает лучше с точки зрения пользовательского опыта, потенциальных клиентов, конверсий или любой другой цели. Предположим, у нас есть интернет магазин и каталог отображается определенным образом. В какой-то момент (новые маркетинговые исследования/пожелания клиента и т. д.) решено изменить дизайн выдачи товаров в каталоге. Независимо от того, сколько проведено анализа, выпуск нового пользовательского интерфейса будет большим изменением и может иметь неприятные последствия.
В этом случае мы можем использовать A / B-тестирование. Мы создадим интерфейс нового варианта и перенаправим часть трафика пользователей на него. Например - мы можем распределить пользователей в соотношении 50:50 или 80:20 между двумя вариантами - A и B. После этого в течение определенного периода времени мы будем наблюдать за статистикой и коэффициентами конверсии обоих вариантов. Таким образом, тестирование A/B помогает принять решение о выборе лучшего варианта.
Исходный вариант (А) называется контроль (control), а альтернативный (B) - вариация (variation). При проведении A / B-тестирования мы получаем данные / статистику от чемпионов, претендентов и вариаций (champions, challengers, and variations). Эти версии дают представление о коэффициентах конверсии ваших посетителей.
Терминология:
Что тестируется с помощью A/B Testing:
Многовариантное тестирование (Multivariate Testing): несколько элементов на странице изменяются в комбинации, она сравнивается с текущей версией веб-страницы. Цель проведения многовариантного тестирования - измерить эффективность каждой комбинации дизайна. Многовариантное тестирование дает более быстрые результаты, но может быть сложным для новичка.
A/B Testing | Multivariate Testing |
позволяет экспериментировать с одним или несколькими вариантами веб-страницы друг против друга. | помогает вам поэкспериментировать с несколькими вариантами нескольких элементов на веб-странице одновременно |
Здесь ваш трафик будет разделен на две разные веб-страницы: версия A и версия B. | Здесь ваш трафик будет разделен на несколько веб-страниц с несколькими вариантами. |
Вам не понадобится большой трафик, чтобы попробовать это тестирование. | Для реализации многовариантного тестирования ваш сайт должен иметь огромные объемы трафика. |
Пример: изменение цвета кнопки покупки. Версия A: цвет по умолчанию Версия B: красный цвет | Пример: изменение основных элементов целевой страницы. Версия A: Headline_3, Img_2, CTA_1 Версия B: Заголовок_1, Img_3, CTA_2 Версия C: Headline_2, Img_4, CTA_1 Версия D: Headline_4, Img_1, CTA_3 |
Тестирование разделением URL (Split URL Testing): вы создаете два или более вариантов для своей веб-страницы. Затем протестируйте эти несколько версий вашего веб-сайта по разным URL-адресам. Здесь варианты представляют собой полностью разработанные веб-страницы и хранятся на сервере, доступ к которому осуществляется через разные URL-адреса;
A/B Testing | Split URL Testing |
Это маркетинговый инструмент, позволяющий выяснить, что лучше всего работает для повышения конверсии, путем разделения трафика между контрольным и вариантом. | Это маркетинговый инструмент, позволяющий выяснить, что лучше всего работает для повышения конверсии, путем разделения трафика по разным URL-адресам. |
Для создания вариантов будут внесены лишь незначительные изменения в элементы в HTML. | Здесь варианты обычно представляют собой полностью разработанную веб-страницу, которая хранится на сервере и к которой можно получить доступ через другой URL-адрес. |
Лучше всего использовать при оптимизации отдельных веб-страниц и часто используется для проведения быстрых тестов. | Можно использовать для больших изменений, например, для новых редизайнов |
Мультистраничное тестирование (Multi-Page Testing): При многостраничном тестировании мы экспериментируем, изменяя определенный элемент на нескольких страницах. Здесь вы должны показывать пользователям сочетание и совпадение вариантов вместо того, чтобы показывать согласованные варианты по набору страниц. Таким образом, мы можем тщательно протестировать один вариант против другого;
Источник:
A/B Testing Guide: How To Perform AB Testing
Доп. материал:
Destructive testing (негативное) - тип тестирования ПО для поиска точек отказа в ПО, который проверяет систему на обработку исключительных ситуаций (срабатывание валидаторов на некорректные данные), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора. Неожиданные условия могут быть чем угодно, от неправильного типа данных до хакерской атаки. Целью Destructive testing является предотвращение сбоя приложений из-за некорректных входных данных. Просто проводя положительное тестирование, мы можем только убедиться, что наша система работает в нормальных условиях, но помимо этого мы должны убедиться, что наша система может справиться и с непредвиденными условиями. Типичные примеры: ввести неправильно составленный e-mail и номер телефона, загрузить файл не предусмотренного расширения или размера.
Для деструктивного тестирования существует множество способов его проведения:
Non Destructive testing (позитивное) - это тип тестирования программного обеспечения, который включает в себя правильное взаимодействие с ПО. Другими словами, неразрушающее тестирование (NDT) также можно назвать позитивным тестированием или тестированием «счастливого пути» (Happy path). Оно дает ожидаемые результаты и доказывает, что программное обеспечение ведет себя так, как ожидалось. Пример: - Ввод правильных данных в модуль входа в систему и проверка, принимает ли он учетные данные и переходит на следующую страницу
Источник:
What is Destructive Testing? Methods, Techniques and Examples
Доп. материал:
В ISTQB и некоторых других источниках эти понятия разделяются:
В других же источниках они используются как синонимы. В любом случае, отдельно по Random testing мне не удалось найти хорошего большого материала, так что оставлю пока как есть.
Monkey Testing - это метод тестирования черного ящика, при котором тестировщик предоставляет случайные входные данные и применяет случайные действия в программном приложении для проверки поведения системы. Это помогает нам оценить, дает ли система сбой при получении таких неожиданных входных данных. Здесь входными данными могут быть данные, которые вводятся в приложение, или нажатие кнопки для следующего действия, или нажатие на ссылку для перехода на другую страницу.
В Monkey testing тестировщиком (иногда и разработчиком) считается «Обезьяна». Если обезьяна использует компьютер, она будет произвольно выполнять любую задачу в системе из своего понимания. Точно так же, как тестировщик будет применять случайные Test case в тестируемой системе, чтобы находить bugs/errors без предварительного определения тестового примера. В некоторых случаях Monkey testing также посвящен модульному тестированию или GUI-тестированию. Основная задача: попытаться сломать систему.
Типы Обезьян:
Gorilla testing проводится в соответствии с методом ручного тестирования, при котором тестировщик многократно тестирует модуль, чтобы проверить его надежность. Здесь разработчик и тестировщик объединяются, чтобы протестировать конкретный модуль во всех аспектах. При тестировании Gorilla каждый модуль приложения берется по одному, и для проверки этих модулей вводится диапазон допустимых и недопустимых входных данных. Эти входные значения берутся случайным образом. Тестирование Gorilla направлено на изучение возможностей отдельных модулей. При тестировании Gorilla каждый второстепенный код приложения проверяется до тех пор, пока он не начнет разваливаться или не даст ожидаемых результатов.
Monkey Testing | Gorilla Testing |
Не использует никаких тестовых примеров для тестирования приложения, это просто случайные входные данные | Гарантирует, что у модуля нет проблем, выполняя повторяющиеся задачи по вставке случайных входных данных в модуль |
Синоним Random testing | Также известно как повторяющееся тестирование или Тестирование на пытки или Тестирование на отказоустойчивость (repetitive testing or Torture Testing or Fault Tolerance Testing) |
Проверяет выполнение всего приложения, используя случайные входные данные, чтобы гарантировать, что система не выйдет из строя из-за неожиданных значений | стремится тщательно протестировать отдельный модуль |
Может быть выполнено любым стейкхолдером проекта | Для проведения тестирования gorilla требуется разработчик или тестировщик с хорошим знанием приложения |
Фокусируется на сбое (crashing) всей системы из-за случайного ввода | фокусируется на тестировании функциональности конкретного модуля |
Monkey Testing | Ad-hoc Testing |
Фокусируется на ломании приложения случайным вводом | Фокусируется на поиске ошибок, которые не были обнаружены существующими кейсами |
Ошибки обнаруживаются на основе случайных входных значений | Ошибки обнаруживаются на основе неисследованных областей приложения |
Тестировщики не знают приложение, они тестируют приложение, случайным образом щелкая или вводя данные, чтобы проверить, не приводит ли это к ошибке | Тестировщик должен хорошо разбираться в приложении и понимать его функции |
От тестировщика не требуется быть экспертом в данной области или иметь какие-либо глубокие знания о приложении. | Тестировщик будет знать точный рабочий процесс приложения вместе со знанием предметной области |
Может быть выполнено любым стейкхолдером | Обычно выполняется тестировщиком, который знает приложение |
Если мы говорим о ручном тестировании, он может быть менее эффективным, чем другие методы черного ящика. Но если мы добавим тулы автоматизации, она станет мощным инструментом. Просто представьте, что кейсы с различными наборами входных данных генерируются, выполняются и оцениваются автоматически в непрерывном цикле, что позволяет вам запускать тысячи и миллионы кейсов в течение разумного времени.
Источник: Monkey Testing Guide
Это тип тестирования программного обеспечения, который проверяет, что каждый software workflow точно отражает данный бизнес-процесс путем тестирования Software Workflows в документе с бизнес-требованиями (BRD - Business Requirements Document). Workflow - это серия задач для получения желаемого результата, которая обычно включает несколько этапов или шагов. Тестирование рабочего процесса также будет включать в себя части системных и интеграционных тестов. Test Model включает тестирование таких артефактов, как: test cases, test procedures, test components, test sub-system, etc.
Процесс Workflow testing:
Кто проводит Workflow testing:
Источник:
What is Workflow Testing in Software Testing? with Examples
Плохая документация может повлиять на качество продукта. Тестирование артефактов, разработанных до, во время и после тестирования продукта, называется тестированием документации. Это нефункциональный тип тестирования программного обеспечения. Мы знаем, что дефекты, обнаруженные на этапе тестирования, более дорогостоящие, чем если бы они были обнаружены на этапе требований. Стоимость исправления ошибки увеличивается тем больше, чем позже вы найдете ее. Таким образом, тестирование документации может начаться с самого начала процесса разработки программного обеспечения, чтобы сэкономить большую сумму денег. Некоторые часто проверяемые артефакты:
Техники тестирования требований:
Взаимный просмотр (peer review). Взаимный просмотр («рецензирование») является одной из наиболее активно используемых техник тестирования требований и может быть представлен в одной из трех следующих форм (по мере нарастания его сложности и цены):
Вопросы. Следующей очевидной техникой тестирования и повышения качества требований является (повторное) использование техник выявления требований, а также (как отдельный вид деятельности) — задавание вопросов. Если хоть что-то в требованиях вызывает у вас непонимание или подозрение — задавайте вопросы. Можно спросить представителей заказчика, можно обратиться к справочной информации. По многим вопросам можно обратиться к более опытным коллегам при условии, что у них имеется соответствующая информация, ранее полученная от заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы полученный ответ позволил улучшить требования;
Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет нам определить, насколько требование проверяемо. Если вы можете быстро придумать несколько пунктов чек-листа, это ещё не признак того, что с требованием всё хорошо (например, оно может противоречить каким-то другим требованиям). Но если никаких идей по тестированию требования в голову не приходит — это тревожный знак. Рекомендуется для начала убедиться, что вы понимаете требование (в том числе прочесть соседние требования, задать вопросы коллегам и т.д.). Также можно пока отложить работу с данным конкретным требованием и вернуться к нему позднее — возможно, анализ других требований позволит вам лучше понять и это конкретное. Но если ничто не помогает — скорее всего, с требованием что-то не так. Справедливости ради надо отметить, что на начальном этапе проработки требований такие случаи встречаются очень часто — требования сформированы очень поверхностно, расплывчато и явно нуждаются в доработке, т.е. здесь нет необходимости проводить сложный анализ, чтобы констатировать непроверяемость требования. На стадии же, когда требования уже хорошо сформулированы и протестированы, вы можете продолжать использовать эту технику, совмещая разработку тест-кейсов и дополнительное тестирование требований.
Исследование поведения системы. Эта техника логически вытекает из предыдущей (продумывания тест-кейсов и чек-листов), но отличается тем, что здесь тестированию подвергается, как правило, не одно требование, а целый набор. Тестировщик мысленно моделирует процесс работы пользователя с системой, созданной по тестируемым требованиям, и ищет неоднозначные или вовсе неописанные варианты поведения системы. Этот подход сложен, требует достаточной квалификации тестировщика, но способен выявить нетривиальные недоработки, которые почти невозможно заметить, тестируя требования по отдельности.
Рисунки (графическое представление). Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т.д. Графическое представление удобно одновременно своей наглядностью и краткостью (например, UML-схема базы данных, занимающая один экран, может быть описана несколькими десятками страниц текста). На рисунке очень легко заметить, что какие-то элементы «не стыкуются», что где-то чего-то не хватает и т.д. Если вы для графического представления требований будете использовать общепринятую нотацию (например, уже упомянутый UML), вы получите дополнительные преимущества: вашу схему смогут без труда понимать и дорабатывать коллеги, а в итоге может получиться хорошее дополнение к текстовой форме представления требований.
Прототипирование. Можно сказать, что прототипирование часто является следствием создания графического представления и анализа поведения системы. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется, что реализованное в прототипе (возможно, с небольшими доработками) устраивает заказчика.
Подробный разбор примера тестирования требований можно прочитать в книге Святослава Куликова “Тестирование программного обеспечения. Базовый курс” в разделе 2.2.7. “Пример анализа и тестирования требований”.
Источники:
Доп. материал:
Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage). Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего. Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь? Ответ на этот вопрос даёт мутационное тестирование.
Мутационное тестирование (MT, Mutation Testing, Mutation Analysis, Program mutation, Error-based testing, Fault-based testing strategy) - это вид тестирования ПО методом белого ящика, основанный на всевозможных изменениях (мутациях) частей исходного кода и проверке реакции на эти изменения набора автоматических юнит тестов. Изменения в мутантной программе сохраняются крайне небольшими, поэтому это не влияет на общее исполнение программы. Если тесты после изменения кода не падают (failed), значит либо этот код недостаточно покрыт тестами, либо написанные тесты бесполезны. Критерий, определяющий эффективность набора автоматических тестов, называется Mutation Score Indicator (MSI).
Введем некоторые понятия из теории мутационного тестирования:
Для применения этой технологии у нас, очевидно, должен быть исходный код (source code), некоторый набор тестов (для простоты будем говорить о модульных — unit tests). После этого можно начинать изменять отдельные части исходного кода и смотреть, как реагируют на это тесты. Одно изменение исходного кода будем называть Мутацией (Mutation). Например, изменение бинарного оператора "+" на бинарный "-" является мутацией кода. Результатом мутации является Мутант (Mutant) — то есть это новый мутированный код. Каждая мутация любого оператора в вашем коде (а их сотни) приводит к новому мутанту, для которого должны быть запущены тесты. Кроме изменения "+" на "-", существует множество других мутационных операторов (Mutation Operator, Mutator, faults or mutation rules), каждый из которых имеет свою цель и применение:
В зависимости от результата теста мутанты делятся на:
Метрики:
Источники:
Доп. материал:
Программное обеспечение (Software) - это управляющий набор инструкций и данных. В информатике и разработке программного обеспечения программное обеспечение - это вся информация, обрабатываемая компьютерными системами, включая программы и данные. Программное обеспечение включает программы, библиотеки и связанные с ними неисполняемые данные, такие как онлайн-документация или цифровые носители. Программное обеспечение и оборудование требуют друг друга, и ни одно из них не может реально использоваться по отдельности. На самом низком уровне программирования исполняемый код состоит из инструкций машинного языка, поддерживаемых отдельным процессором - обычно центральным процессором (ЦП) или графическим процессором (ГП). Машинный язык состоит из групп двоичных значений, обозначающих инструкции процессора, которые изменяют состояние компьютера по сравнению с его предыдущим состоянием.
Аппаратное обеспечение (Hardware) - это физическое электронное устройство, промышленное оборудование или компонент компьютера. Примерами оборудования компьютера являются CPU, MB, устройства ввода/вывода и хранения данных (HDD или SSD). Без оборудования программному обеспечению не на чем будет работать. Аппаратное и программное обеспечение взаимодействуют друг с другом, и программное обеспечение сообщает аппаратному обеспечению, какие задачи оно должно выполнять.
Разница в тестировании ПО и железа:
В глобальном смысле нам не сильно важна природа объекта тестирования, т.к. принципы особо не меняются. Однако, как говорится, есть нюансы:
Источники:
Доп. материал:
Обычно большинство команд тестирования выполняют свои тесты по одному. Этот процесс называется последовательным тестированием или серийным тестированием (sequential testing or serial testing). В процессе последовательного тестирования каждый тестовый пример запускается один за другим и следующий тест не начинается, пока не завершится предыдущий. Последовательный процесс тестирования требует много времени, усилий и ресурсов. Чтобы выпускать качественные продукты в кратчайшие сроки, более эффективным будет параллельное тестирование.
Параллельное тестирование включает в себя в основном автоматизированное тестирование нескольких версий одного и того же приложения или разных компонентов приложения одновременно и с одинаковыми входными данными, чтобы сократить общее время выполнения теста путем интеграции фреймворка автоматизации с облачными решениями и виртуализацией.
Пример: когда какая-либо организация переходит от старой системы к новой, legacy является важной частью. Передача этих данных является сложным процессом. При тестировании программного обеспечения проверка совместимости вновь разработанной системы со старой системой осуществляется посредством «параллельного тестирования».
Источники:
Доп. материал:
Сегодняшний мир переживает очередную технологическую революцию, одним из аспектов которой является использование всевозможными компаниями накопленных данных для раскрутки собственного маховика продаж, прибылей и пиара. Представляется, что именно наличие хороших (качественных) данных, а также умелых мозгов, которые смогут из них делать деньги (правильно обработать, визуализировать, построить модели машинного обучения и т. п.), стали сегодня ключом к успеху для многих. Естественно, это потребовало технической организации этого процесса — подсоединиться к источнику данных, выкачать их, проверить, что они загружены в полном объёме и т. п. Количество таких процессов стало расти, и на сегодняшний день мы получили огромную потребность в Data Quality инженерах - тех, кто следил бы за потоком данных в системе (data pipelines), за качеством данных на входе и на выходе, делал бы выводы об их достаточности, целостности и прочих характеристиках. Обязанности Data Quality инженера не ограничиваются только рутинными ручными/автоматическими проверками на «nulls, count и sums» в таблицах БД, а требуют глубокого понимания бизнес нужд заказчика и, соответственно, способностей трансформировать имеющиеся данные в пригодную бизнес-информацию.
Data Quality — один из этапов Data Management и первый пункт плана управления данными (data management plan).
Аспекты качественных данных (dimensions):
Сам процесс тестирования не подразумевает строгое копирование этих признаков в тест-кейсы и их проверку. В Data Quality, как и в любом другом виде тестирования, необходимо прежде всего отталкиваться от требований по качеству данных, согласованных с участниками проекта, принимающими бизнес-решения.
Пример самого обобщенного перечня активностей Data Quality инженера:
При этом основной акцент проверок должен приходиться не только на то, что поток данных в системе в принципе отработал и дошёл до конца (что является частью функционального тестирования), а по большей части на проверку и валидацию данных на предмет соответствия ожидаемым требованиям, выявления аномалий и прочего.
Источники + доп. материал:
Впервые упоминание встречается в 2010 году у Jimmy Bougard в блоге: ”В то время как модульный тест фокусируется на мелкомасштабном дизайне, подкожный тест не касается дизайна, а вместо этого проверяет основные входы и выходы системы в целом”, затем в докладе Matt Davies and Rob Moore - “Microtesting - How We Set Fire To The Testing Pyramid While Ensuring Confidence”, а позже и в презентации Daniel Lafeir and Michael Lawrie. Термин «подкожный» означает автоматизированный тест непосредственно под слоем пользовательского интерфейса. В приложении MVC это будут тесты для всего, что находится непосредственно под контроллером. Для веб-службы все, что находится ниже ендпоинта (endpoint).
Идея состоит в том, что самый верхний уровень в приложении не выполняет никакой реальной бизнес-логики, а просто соединяет внешние интерфейсы с базовыми службами. Как подчеркивает Martin Fowler в своем сообщении о подкожном тестировании, такие тесты особенно полезны при попытке выполнить функциональные тесты, когда вы хотите реализовать сквозной сценарий, избегая при этом некоторых трудностей, связанных с тестированием через сам пользовательский интерфейс:
Таким образом определение можно сформулировать так: “Если модульный тест тестирует наименьший тестируемый компонент кода приложения, то подкожный тест представляет собой единый рабочий процесс (workflow), который можно идентифицировать и протестировать в коде приложения. Подкожное тестирование рассматривает рабочий процесс как тестируемую единицу”.
Стоит помнить, что это не прямая замена автоматизации тестирования через UI, а просто более целенаправленное тестирование функциональности на нужном уровне приложения. Это позволяет команде создавать более совершенные сквозные тесты с использованием существующего кода, фреймворка и / или библиотек, доступных для внешнего приложения. Основная цель этого вида тестирования - уменьшить нестабильность теста и сосредоточиться на функциональности. Это позволяет группе различать функциональные сбои из-за проблем с кодом и сбои приложений из-за проблем совместимости или проблем с внешними зависимостями. Поскольку подкожные тесты можно запускать с той же тестовой средой, что и модульные тесты, они не имеют доступа к внутреннему коду или вызовам API во время работы. Изоляция этих тестов и использование имитирующих инструментов, которые могут имитировать вызовы API и заглушки для различных взаимодействий служб, могут дать целенаправленную, изолированную оценку функциональности во внешнем стеке. Такое тестирование функциональности позволяет сделать любую автоматизацию через браузер и пользовательский интерфейс более легкими. Это означает, что традиционные тесты пользовательского интерфейса могут быть очень минимальными и проверять только то, что связи работают между уровнями приложения. Вместо использования дорогостоящих тестов графического интерфейса и пользовательского интерфейса для получения информации о функциональности они могут быть поверхностными проверками работоспособности или дымовыми тестами. Избегая использования автоматизации пользовательского интерфейса, утверждающей ожидание чего-то функционально работающего, тесты могут утверждать, правильно ли приложение обменивается данными на своих уровнях интеграции.
Поскольку при подкожном тестировании используются все компоненты на странице, создание интегрированных тестов, которые тестируют только несколько компонентов, или тестирование одного компонента на уровне модуля может не потребоваться. Модульные тесты могут быть нацелены на более сложную логику, а не пытаться протестировать всю логику вокруг одного компонента, тестирование базовой логики облегчает нагрузку на модульное тестирование. Подкожное тестирование использует ту же структуру тестирования (например, Jest), что и модульные тесты. Это сохраняет функциональные тесты внутренними и ближе к коду, что дает команде больше шансов на более быструю обратную связь и более быструю настройку теста, чем тестовая среда, поддерживаемая отдельно. Это означает, что командам не нужно выполнять дополнительную работу по сопровождению нескольких фреймворков, репозиториев, а иногда и языков для выполнения функционального тестирования пользовательского интерфейса. Теперь, когда подкожное тестирование позволяет проводить функциональное тестирование кода, а не через пользовательский интерфейс, любые тесты пользовательского интерфейса могут быть сокращены до небольшой части того, что было необходимо ранее. UI-тесты можно использовать как дымовые тесты. Таким образом они могут доказать, что приложение и все его уровни находятся в работоспособном состоянии связи.
Поскольку подкожные тесты ориентированы на поведение высокого уровня (high-level behavior), а не на дизайн, они идеально подходят для стратегий тестирования на основе сценариев (scenario-based testing strategies), таких как BDD или паттерн Testcase Class per Fixture.
К сожалению, наряду со всеми плюсами subcutaneous подхода мы можем получить и снижение покрытия (coverage), в частности glue code (Связующий код — программный код, который служит исключительно для «склеивания» разных частей кода, и при этом не реализует сам по себе никакую иную прикладную функцию). Насколько важна\существенна потеря покрытия в данном случае? Зависит от ситуации. Мы потеряли немного glue code, который может быть (а может и не быть) важным (рекомендую в качестве упражнения определить, какой код потерялся). Оправдывает ли данная потеря покрытия введения тяжеловесного тестирования на уровне UI? Это тоже зависит от ситуации. Мы можем, например:
Один из способов избежать потери покрытия - “Feature Tests Model”
Источники:
Тест-дизайн - важный этап STLС, а именно деятельность по получению и определению тестовых примеров из условий тестирования (test conditions), где условие тестирования - это «аспект основы тестирования (test basis), который важен для достижения конкретных целей тестирования», а основа тестирования - это «совокупность знаний, используемая в качестве основы для анализа и дизайна тестов (test analysis and test design)». Проще говоря, цель тест-дизайна - создать максимально эффективный набор кейсов, покрывающий наиболее важные аспекты тестируемого ПО, т.е. минимизировать количество тестов, необходимых для нахождения большинства серьезных ошибок.
Одним из наиболее важных аспектов теста является то, что он проверяет, выполняет ли система то, что она должна делать. Copeland говорит: “По сути, тестирование - это процесс сравнения того, что есть с тем, что должно быть”. Если мы просто введем какие-то данные и подумаем, что это было весело, я предполагаю, что с системой, вероятно, все в порядке, потому что она не крашнулась, но действительно ли мы ее тестируем? Beizer называет это «детским тестированием» (kiddie testing). Мы можем не знать каждый раз, какой правильный ответ в деталях, и иногда мы все равно можем получить некоторую выгоду от этого подхода, но на самом деле это не проверка. Чтобы знать, что система должна делать, нам нужен источник информации о правильном поведении системы - это называется «оракул» или тестовый оракул (test oracle). После того, как заданное входное значение было выбрано, тестировщику необходимо определить, каким будет ожидаемый результат ввода этого входа, и задокументировать его как часть тестового примера.
Давайте проясним. Требования или пользовательские истории с критериями приемлемости (формы test basis) определяют, что вы должны тестировать (test objects and test conditions), и исходя из этого, вы должны выяснить способ тестирования, то есть спроектировать тестовые примеры. Один из наиболее важных вопросов заключается в следующем: какие факторы влияют на успешный дизайн теста? Если вы читаете разные блоги, статьи или книги, вы найдете примерно следующее:
Это неправда! Без достаточного времени и бюджета вы, вероятно, вообще не начнете ни одного проекта. Если у вас нет квалифицированных специалистов по тестированию программного обеспечения, включая дизайн тестов, то, вероятно, вы тоже не начнете проект. Однако, хороший дизайн теста включает три предварительных условия:
Требуются некоторые пояснения. Полная спецификация не означает безошибочную спецификацию, так как во время разработки теста можно найти и исправить множество проблем (предотвращение дефектов). Это только означает, что у нас есть все необходимые требования или в Agile разработке у нас есть все эпики, темы и пользовательские истории с критериями приемлемости (acceptance criteria). Существует минимальная ценность в одновременном рассмотрении затрат на тестирование и затрат на исправление дефектов, и цель хорошего тест-дизайна - выбрать подходящие методы тестирования, приближающиеся к этому минимуму. Это можно сделать, проанализировав сложность, риски и используя исторические данные. Таким образом, анализ рисков неизбежен для определения тщательности тестирования. Чем выше риск использования функции / объекта, тем более тщательное тестирование необходимо. То же самое можно сказать и о сложности кода. Для более рискованного или сложного кода мы должны сначала применить больше НЕкомбинаторных методов проектирования тестов вместо одного чисто комбинаторного.
Наше другое и правильное представление о дизайне тестирования состоит в том, что если у вас есть соответствующая спецификация (тестовая база) и надежный анализ рисков и сложности, то, зная ваши исторические данные, вы можете выполнить дизайн теста оптимальным образом. Вначале у вас нет исторических данных, и вы, вероятно, не достигнете оптимума. Нет проблем, давайте сделаем предварительную оценку. Например, если риск и сложность низкие, используйте только исследовательское тестирование. Если они немного выше, используйте исследовательское тестирование и простые методы, основанные на спецификациях, такие как классы эквивалентности с анализом граничных значений. Если риск высок, вы можете использовать исследовательское тестирование, комбинационное тестирование, предотвращение дефектов, статический анализ и обзоры (reviews).
Еще одно важное замечание. Критерии выбора тестов и адекватности тестовых данных различны. Первый - неотъемлемая часть любой техники тест-дизайна. Второй проверяет набор тестов. В результате процесса разработки тестов создаются независимые от реализации тестовые примеры, которые проверяют требования или пользовательские истории. Напротив, тесты, которые создаются на основе отсутствия покрытия по выбранным критериям адекватности тестовых данных, подтверждают проблемы, зависящие от реализации; однако это НЕ дизайн теста, это создание теста. Очень важно использовать метод «сначала тестирование» (test-first method), т. е. дизайн теста должен быть отправной точкой разработки. Дизайн тестов также очень эффективен для предотвращения дефектов, если он применяется до внедрения.
Итак, хороший процесс тест-дизайна выглядит так:
Затем вам нужно будет выбрать технику тест-дизайна для каждого требования. На этом этапе, если все реализовано правильно, вы можете внести значительные изменения, которые чрезвычайно повлияют на ваш ROI.
Роли, ответственные за тест дизайн:
Попросту говоря, задача тест аналитиков и дизайнеров сводится к тому, чтобы используя различные стратегии и техники тест дизайна, создать набор Test case, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. Однако, на большинстве проектов эти роли не выделяется, а доверяется обычным тестировщикам, что не всегда положительно сказывается на качестве тестов, тестировании и, как из этого следует, на качестве ПО (конечного продукта).
Техники тест-дизайна (Software testing techniques)
Источники:
Доп. материал:
Методы статического тестирования делятся на две основные категории, одной из которых являются ревью. Ранжирование по уровню формальности:
Экспертные обзоры (Peer Reviews): Рецензирование - это стандартизированный метод проверки правильности исходного кода (методом белого ящика) при разработке программного обеспечения, который проводится для выявления дефектов на ранних этапах жизненного цикла и которые не могут быть обнаружены с помощью методов тестирования черного ящика.
Прохождение/просмотр/пошаговый разбор (walkthrough ): это метод проведения неформального группового / индивидуального просмотра. В walkthrough автор описывает и объясняет рабочий продукт на неформальной встрече своим коллегам или руководителю, чтобы получить обратную связь. Здесь проверяется применимость предложенного решения для рабочего продукта. Либо рабочий продукт проверяется на наличие дефектов несколькими лицами, кроме человека, который его фактически произвел;
Технический обзор (Technical Review): Это метод более высокого уровня по сравнению с inspection или walkthrough, поскольку он также включает в себя управление. Этот метод используется для оценки (assess and evaluate) продукта путем проверки его соответствия стандартам разработки, руководствам и спецификациям. У него нет определенного процесса, и большая часть работы выполняется модератором, как описано ниже:
Инспекция: Инспекция определяется как наиболее формальная, тщательная, глубокая групповая проверка, направленная на выявление проблем как можно ближе к их исходной точке. Процесс проверки выполняется на ранних этапах SDLC и применяется к определенной части продукта, такой как SRS, код, дизайн продукта. и т. д. Это включает в себя ручное изучение различных компонентов продукта на более ранних этапах. Инспекционная деятельность следует определенному процессу, и участники играют четко определенные роли. Инспекционная группа состоит из трех-восьми человек, которые играют роли модератора, автора, читателя, записывающего и инспектора. Например, разработчик может выступать в качестве инспектора во время проверки кода, в то время как представитель по обеспечению качества может действовать как исполнитель стандартов.
Software inspection process:
Источники:
Статический анализ - это анализ программных артефактов, таких как программный код (или требования, дизайн), выполняемый статически, т.е. без запуска и, очевидно, методом белого ящика. Основная цель этого анализа - как можно раньше найти ошибки, независимо от того, могут ли они вызывать отказы (failures). Как и в случае с обзорами (reviews), статический анализ обнаруживает ошибки (bugs), а не отказы. Обычно статический анализ проводят до формальной проверки, даже до unit testing, путём добавления этих проверок специалистами DevOps в пайплайн проекта. Статический анализ не связан с динамическими свойствами требований, дизайна и кода, такими как покрытие тестами (test coverage). Существует множество инструментов для статического анализа, которые в основном используются разработчиками до или во время тестирования компонентов или интеграции (чаще новые и измененные классы и функции), а также дизайнерами во время моделирования программного обеспечения. Инструменты могут отображать не только структурные атрибуты, такие как глубина вложенности или число цикломатической сложности и проверка на соответствие стандартам кодирования, но также графические изображения потока управления, взаимосвязи данных и количество отдельных путей от одной строки кода к другой. Информация может использоваться вплоть до формальных методов, которые математически подтверждают свойства данной программы.
Инструменты помогают в выявлении следующих дефектов:
Методы статического анализа:
Анализ потока управления (Control Flow Analysis) и анализ потока данных (Data Flow Analysis) взаимозависимы: чтобы получить точные результаты для анализа потока данных, необходимо учитывать поток управления (поскольку порядок операций влияет на возможные значения данных в конкретном месте программы). Чтобы получить точные результаты для анализа потока управления, необходимо учитывать поток данных, поскольку поток динамического управления (решение, принимаемое во время выполнения) зависит от значений данных в конкретных местах программы. Однако эти два анализа преследуют разные цели.
Граф потока управления (Control Flow Graph)
Граф потока управления (CFG) - это графическое представление потока управления или вычислений во время выполнения программ или приложений. Графы потока управления в основном используются в статическом анализе, а также в приложениях-компиляторах, поскольку они могут точно представлять поток внутри программного модуля. Характеристики графа потока управления:
Полное описание возможных элементов графа.
Цикломатическая сложность (Cyclomatic Complexity)
Цикломатическая сложность - это метрика для измерения сложности кода, основанная на графе потока управления. Независимый путь определяется как путь, имеющий хотя бы одно ребро, которое ранее не проходило ни в одном другом пути.
Определение из книги Ли Копланда - “A Practitioner's Guide to Software Test Design”, Главы 10:
Цикломатическая сложность - это конечное минимальное количество независимых, нецикличных маршрутов (называемых основными маршрутами), которые могут образовывать все возможные линейные пути в программном модуле.
Цикломатическая сложность может быть рассчитана относительно функций, модулей, методов или классов в программе как вручную, так и с помощью автоматизированных инструментов.
Математически цикломатическая сложность структурированной программы определяется с помощью ориентированного графа, узлами которого являются блоки программы, соединенные ребрами, если управление может переходить с одного блока на другой. Тогда сложность определяется как
M = E − N + 2P,
где:
В другой формулировке используется граф, в котором каждая точка выхода соединена с точкой входа. В этом случае граф является сильносвязным, и цикломатическая сложность программы равна цикломатическому числу этого графа (также известному как первое число Бетти), которое определяется как
M = E − N + P.
Это определение может рассматриваться как вычисление числа линейно независимых циклов, которые существуют в графе, то есть тех циклов, которые не содержат в себе других циклов. Так как каждая точка выхода соединена с точкой входа, то существует по крайней мере один цикл для каждой точки выхода.
Для простой программы, или подпрограммы, или метода P всегда равно 1. Однако цикломатическая сложность может применяться к нескольким таким программам или подпрограммам (например, ко всем методам в классе), в таком случае P равно числу подпрограмм, о которых идет речь, так как каждая подпрограмма может быть представлена как независимая часть графа.
Может быть показано, что цикломатическая сложность любой структурированной программы с только одной точкой входа и одной точкой выхода эквивалентна числу точек ветвления (то есть, операторов if или условных циклов), содержащихся в этой программе, плюс один.
Цикломатическая сложность может быть распространена на программу с многочисленными точками выхода; в этом случае она равна
π − s + 2,
где:
Применение:
Источники:
Доп. материал:
Динамическое тестирование методом белого ящика - это стратегия, основанная на внутренних путях, структуре и реализации тестируемого программного обеспечения. Тесты здесь выполняются динамически, т.е. с запуском объекта тестирования и основаны на различных видах покрытии кода (путей исполнения программы).
Глобально основных техник динамического тестирования методом белого ящика всего две:
Фактически, это динамическая часть одного цельного тестирования, статическая часть которого - анализ и построение графа, описывается в предыдущей теме про статический анализ, а на этом определяется целевое покрытие (Coverage Target), создаются соответствующие тест-кейсы, тесты исполняются и результаты выполнения тестов анализируются.
Под “покрытием" имеется в виду отношение объема кода, который уже был проверен, к объему, который осталось проверить. В тестировании потока управления покрытие определяется в виде нескольких различных уровней. Заметим, что эти уровни покрытия представлены не по порядку. Это потому, что в некоторых случаях проще определить более высокий уровень покрытия, а затем определить более низкий уровень покрытия в условиях высокого.
100% покрытие операторов (Statement/node coverage). Оператор (statement) - это сущность языка программирования, обычно являющаяся минимальным неделимым исполняемым блоком (ISTQB). Покрытие операторов - это метод проектирования тестов методом белого ящика, который включает в себя выполнение всех исполняемых операторов (if, for и switch) в исходном коде как минимум один раз. Процентное отношение операторов, исполняемых набором тестов, к их общему количеству является метрикой покрытия операторов. Борис Бейзер написал: "тестирование, меньшее чем это [100% покрытие операторов], для нового программного обеспечения является недобросовестным и должно быть признано преступлением. …”. Несмотря на то, что это может показаться разумной идеей, на таком уровне покрытия может быть пропущено много дефектов и затруднен анализ покрытия некоторых управляющих структур. Покрытие операторов позволяет найти:
100% покрытие альтернатив/ветвей (Decision/branch/all-edges/basis path/DC/C2/ decision-decision-path/edge coverage). «Решение» - это программная точка, в которой control flow имеет два или более альтернативных маршрута (ветви). На этом уровне достаточно такого набора тестов, в котором каждый узел с ветвлением (альтернатива), имеющий TRUE или FALSE на выходе, выполняется как минимум один раз, таким образом, для покрытия по веткам требуется как минимум два тестовых примера. На данном уровне не учитываются логические выражения, значения компонент которых получаются вызовом функций. В отличие от предыдущего уровня покрытия данный метод учитывает покрытие условных операторов с пустыми ветками. Покрытие альтернатив не гарантирует покрытие всех путей, но при этом гарантирует покрытие всех операторов;
Для более полного анализа компонент условий в логических операторах существуют следующие три метода, учитывающих структуру компонент условий и значения, которые они принимают при выполнении тестовых примеров.
100% покрытие условий (Condition/Toggle Coverage). Рассматриваются только выражения с логическими операндами, например, AND, OR, XOR. На этом уровне достаточно такого набора тест-кейсов, в котором каждое условие, имеющее TRUE и FALSE на выходе, выполнено как минимум один раз. Покрытие условий обеспечивает лучшую чувствительность к control flow, чем decision coverage. Для обеспечения полного покрытия по данному методу каждая компонента логического условия в результате выполнения тестовых примеров должна принимать все возможные значения, но при этом не требуется, чтобы само логическое условие принимало все возможные значения, т.е. Condition Coverage не дает гарантии полного decision coverage;
100% покрытие условий + альтернатив (Decision + Condition coverage). На этом уровне тест-кейсы создаются для каждого условия и для каждой альтернативы, т.е. данный метод сочетает требования предыдущих двух методов - для обеспечения полного покрытия необходимо, чтобы как логическое условие, так и каждая его компонента приняла все возможные значения;
100% покрытия множественный условий (Multiple condition coverage). Для выявления неверно заданных логических функций был предложен метод покрытия по всем условиям. При данном методе покрытия должны быть проверены все возможные наборы значений компонент логических условий: условий, альтернатив и условий/альтернатив. Т.е. в случае n компонент потребуется 2^n тестовых примеров, каждый из которых проверяет один набор значений. Тесты, необходимые для полного покрытия по данному методу, дают полную таблицу истинности для логического выражения. Несмотря на очевидную полноту системы тестов, обеспечивающей этот уровень покрытия, данный метод редко применяется на практике в связи с его сложностью и избыточностью. Еще одним недостатком метода является зависимость количества тестовых примеров от структуры логического выражения. Кроме того, покрытие множественных условий не гарантирует покрытие всех путей;
Покрытие бесконечного числа путей. Если, в случае зацикливания, количество путей становится бесконечным, то имеет смысл существенно их сократить, ограничив количество циклов выполнения, что позволит уменьшить количество тестовых случаев. Первый вариант - не выполнять цикл совсем; второй - выполнить цикл один раз; третий - выполнить цикл n раз, где n - это небольшое значение, представляющее символическое количество повторений цикла; четвертый - выполнить цикл m раз, где m - максимальное количество повторений цикла. Кроме того, можно выполнить цикл m-1 и m+1 раз. Перед тем, как начинать тестирование потока управления, должен быть выбран соответствующий уровень покрытия;
100% покрытие путей (Path coverage). Проверяет каждый линейно независимый путь в программе, что означает, что число тестовых примеров будет эквивалентно цикломатической сложности программы. Для кода модулей без циклов количество путей, как правило, достаточно мало, поэтому на самом деле можно построить тест-кейсы для каждого пути. Для модулей с циклами количество путей может быть огромным, что представляет неразрешимую проблему тестирования.
Путь на самом деле является направлением, потоком выполнения, который следует за последовательностью инструкций. Он охватывает функцию от входа до точки выхода. Он охватывает statement, branch/decision coverage. Покрытие пути можно понять в следующих терминах:
7 вышеперечисленных уровней описываются в книге Копленда “A Practitioner's Guide to Software Test Design”, но можно найти и другие
FSM coverage (Finite State Machine Coverage)
Конечные автоматы (FSM) имеют конечное число состояний, условий, которые приводят к внутренним переходам между состояниями, и соответствующее поведение ПО в каждом состоянии автомата. Автомат обычно моделирует поведение управляющей логики.
Покрытие FSM - покрытие конечного автомата, безусловно, является наиболее сложным методом покрытия кода. В этом методе покрытия вам нужно посмотреть, как много было переходов/посещений определенных по времени состояний (time-specific states). Оно также проверяет, сколько последовательностей включено в конечный автомат. Конечные автоматы могут иметь множество ветвей и несколько функциональных путей, а также любой скрытый путь (функциональный путь, пропущенный при проверке, или путь, непреднамеренно введенный на этапе реализации) в дизайне может вызвать серьезное нарушение функциональности, а также может создать тупик (система не может самостоятельно выйти из определенного состояния, даже если намеченный стимул присутствует).
Basis Path testing
Цель тестирования базового пути - в отличии от D-D Path (Decision-to-decision path) получить полное покрытие тех путей, которые находятся между точками принятия решений (decisions points) с высоким бизнес-риском и высокой бизнес-ценностью, т.к. проверять все возможные пути обходится слишком дорого. Это гибрид branch testing и path testing
LCSAJ coverage
LCSAJ (linear code sequence and jump) «линейная последовательность кода и переход». Каждый LCSAJ представляет собой сегмент кода, который выполняется последовательно от начальной точки до конечной точки, а затем прерывает последовательный поток для передачи потока управления. Каждая строка кода имеет плотность (density), то есть количество раз, когда номер строки появляется в LCSAJ.
Один LCSAJ состоит из трех компонентов:
Его основное применение при динамическом анализе программного обеспечения, чтобы помочь ответить на вопрос «Сколько тестирования достаточно?». Динамический анализ программного обеспечения используются для измерения качества и эффективности тестовых данных программного обеспечения, где количественное определение выполняются в терминах структурных единиц кода при тестировании. В более узком смысле, LCSAJ является хорошо определенным линейным участком кода программы. При использовании в этом смысле, LCSAJ также называют JJ-путь (jump-to-jump path). 100% LCSAJ означает 100% Statement Coverage, 100% Branch Coverage, 100% procedure или Function call Coverage, 100% Multiple condition Coverage (в ISTQB говорится только о 100% Decision coverage).
Определенные метрики используются для проверки покрытия кода. Эти показатели могут помочь нам определить, достаточно ли тестирования или нет. Эти показатели называются коэффициентом эффективности тестирования (TER - Test Effectiveness Ratio):
Исследователи ссылаются на коэффициент покрытия путей длиной n LCSAJ как на коэффициент эффективности теста (TER) n + 2.
Тестирование потока данных - это еще один набор методов / стратегий белого ящика, который связан с анализом потока управления, но с точки зрения жизненного цикла переменной. Переменные определяются, используются и уничтожаются, когда в них больше нет необходимости. Аномалии в этом процессе, такие как использование переменной без ее определения или после ее уничтожения, могут привести к ошибке. Рапс и Вьюкер, популяризаторы данного метода, писали: "Мы уверены, что, как нельзя чувствовать себя уверенным в программе без выполнения каждого ее оператора в рамках какого-то тестирования, так же не следует быть уверенным в программе без видения результатов использования значений, полученных от любого и каждого из вычислений".
Когда «поток данных» через информационную систему представлен графически, он известен как диаграмма потока данных (Data Flow Diagram). Она также используется для визуализации обработки данных. Но не нужно путать это с графом потока данных (Data Flow Graph), который используется в Data Flow Testing. Граф потока данных похож на граф потока управления тем, что показывает поток обработки через модуль. Дополнительно к этому, он детализирует определение, использование и уничтожение каждой из переменных модуля. Мы построим эти диаграммы и убедимся, что шаблоны определение-использование-уничтожение являются подходящими. Сначала мы проведем статический анализ. Под "статическим" мы имеем в виду, что мы исследуем диаграмму (формально через проверки или неформально беглыми просмотрами). Потом мы проведем динамические тесты модуля. Под "динамическими" мы понимаем, что мы создаем и исполняем тестовые сценарии.
Так как тестирование потока данных основано на потоке управления модуля, то, предположительно, поток управления в основном верный. Процесс тестирования потока данных сводится к выбору достаточного количества тестов, таких как:
Чтобы сделать это, перечислим маршруты в модуле. Порядок выполнения такой же, как и в случае с тестированием потока управления: начинаем с точки входа в модуль, строим самый левый маршрут через весь модуль и заканчиваем на выходе из него. Возвращаемся в начало и идём по другому направлению в первом разветвлении. Прокладываем этот путь до конца. Возвращаемся в начало и идём по другому направлению во втором разветвлении, потом в третьем и т.д., пока не пройдем все возможные пути. Затем создадим хотя бы один тест для каждой переменной, чтобы покрыть каждую пару определение-использование.
Существуют условные обозначения, которые могут помочь в описании последовательных во времени пар в жизненном цикле переменной:
Таким образом, ~ d, du, kd, ud, uk, uu, k ~, u ~ являются вполне допустимыми комбинациями, когда ~ u, ~ k, dd, dk, kk, ku, d ~ являются аномалиями, потенциальными или явными ошибками. В настоящее время практически все они эффективно обнаруживаются компиляторами или, по крайней мере, IDE, и нам редко требуется выполнять статический анализ для обнаружения этих аномалий. То же самое относится и к динамическому анализу, который сфокусирован на исследовании / выполнении du пар - современные языки программирования снижают вероятность возникновения проблем, связанных с du. Так что в настоящее время такая проверка в основном не стоит усилий.
Источники:
Доп. материал:
Все specification-based или Black Box testing techniques могут быть удобно описаны и систематизированы с помощью следующей таблицы:
Группа | Техника | Когда используется |
Элементарные техники:
| Equivalence Partitioning | Входные и выходные параметры имеют большое количество возможных значений |
Boundary Value Analysis | Значения параметров имеют явные (например, четко определенные в документации) границы и диапазоны или неявные (например, известные технические ограничения) границы | |
Комбинаторные стратегии:
| All Combinations | Количество возможных комбинаций входных значений достаточно мало, или каждая отдельная комбинация входных значений приводит к определенному выходному значению |
Pairwise Testing | Количество входных комбинаций чрезвычайно велико и должно быть сокращено до приемлемого набора кейсов | |
Each Choice Testing | У вас есть функции, при которых скорее конкретное значение параметра вызывает ошибку, нежели комбинация значений | |
Base Choice Testing | Вы можете выделить набор значений параметров, который имеет наибольшую вероятность использования | |
Продвинутые техники:
| Decision Table Testing | Существует набор комбинаций параметров и их выходных данных, описываемых бизнес-логикой или другими правилами |
Classification Tree Method | У вас есть иерархически структурированные данные, или данные могут быть представлены в виде иерархического дерева | |
State Transition Testing | В функциональности есть очевидные состояния, переходы которых регулируются правилами (например, потоки) | |
Cause-Effect Graphing | Причины (входы) и следствия (выходы) связаны большим количеством сложных логических зависимостей | |
Scenario Testing | В функционале есть четкие сценарии | |
Другие техники | Random Testing | Вам необходимо имитировать непредсказуемость реальных вводных данных, или функциональность имеет несистематические дефекты |
Syntax Testing | Функциональность имеет сложный синтаксический формат для входных данных (например, коды, сложные имена электронной почты и т. д.) |
Эквивалентное разделение (Equivalence Partitioning (ISTQB/Myers 1979) / Equivalence Class Testing (Lee Copeland))
Класс эквивалентности представляет собой набор данных, которые либо одинаково обрабатываются модулем, либо их обработка выдает одинаковые результаты. При тестировании любое значение данных, входящее в класс эквивалентности, аналогично любому иному значению класса.
Эквивалентное разделение - это разделение всего набора данных ввода / вывода на такие разделы. Таким образом, вам не нужно выполнять тесты для каждого элемента подмножества, и достаточно одной проверки, чтобы охватить все подмножество. Хитрость заключается в том, чтобы увидеть и идентифицировать разделы, т.к. далеко не всегда они представляют собой числа.
Пример: Мы пишем модуль для системы отдела кадров, который определяет, в каком порядке нужно рассматривать заявления о приеме на работу в зависимости от возраста кандидата.
Правила нашей организации таковы:
Что в коде выглядит как:
Из чего очевидно, что вместо 100 кейсов нам понадобится 4 по числу эквивалентных классов, все остальные кейсы внутри своих классов будут давать одинаковый результат тестов и являются избыточными.
Теперь мы готовы начать тестирование? Вероятно, нет. Что насчет таких входных данных как 969, -42, FRED или &$#! ? Должны ли мы создавать тестовые сценарии для некорректных входных данных? Для того, чтобы понять ответ, мы должны проверить подход, который пришел из объектно-ориентированного мира, названный "проектирование-по-контракту".
В подходе "проектирование-по-контракту" модули (в парадигме объектно-ориентированного программирования они называются "методами", но "модуль" является более общим термином) определены в терминах предусловий и постусловий. Постусловия определяют, что модуль обещает сделать (вычислить значение, открыть файл, напечатать отчет, обновить запись в базе данных, изменить состояние системы и т.д.). Предусловия описывают требования к модулю, при которых он переходит в состояние, описываемое постусловиями.
Например, если у нас есть модуль "openFile", что он обещает сделать? Открыть файл. Какие будут разумные предусловия для этого модуля?
Предусловия и постусловия основывают контракт между модулем и всеми, кто его вызывает. Тестирование-по-контракту основывается на философии проектирования-по-контракту. При использовании данного подхода мы создаем только те тест-кейсы, которые удовлетворяют нашим предусловиям. Например, мы не будем тестировать модуль "openFile", если файл не существует. Причина проста. Если файл не существует, то openFile не обещает работать. Если не существует требования работоспособности в определенных условиях, то нет необходимости проводить тестирование в этих условиях.
В этот момент тестировщики обычно возражают. Да, они согласны, что модуль не претендует на работу в этом случае, но что делать, если предусловия нарушаются в процессе разработки? Что делать системе? Должны ли мы получить сообщение об ошибке на экране или дымящуюся воронку на месте нашей компании? Другим подходом к проектированию является оборонительное проектирование. В этом случае модуль предназначен для приема любого входного значения. Если выполнены обычные предусловия, то модуль достигнет своих обычных постусловий. Если обычные предварительные условия не выполняются, то модуль сообщит вызывающему, возвратив код ошибки или бросив исключение (в зависимости от используемого языка программирования). На самом деле, это уведомление является еще одним из постусловий модуля.
На основе этого подхода мы могли бы определить оборонительное тестирование: подход, который анализирует как обычные, так и необычные предварительные условия.
Нужно ли нам делать проверку с такими входными значениями, как -42, FRED и &$#! @? Если мы используем проектирование-по-контракту и тестирование-по-контракту, то ответ "Нет". Если мы используем оборонительное проектирование и, поэтому, оборонительное тестирование, то ответ "Да". Спросите ваших проектировщиков, какой подход они используют. Если их ответом будет «контрактный» либо «оборонительный», то вы знаете, какой стиль тестирования использовать. Если они ответят "Хм?", то это значит, что они не думают о том, как взаимодействуют модули. Они не думают о предусловиях и постусловиях контрактов. Вам стоит ожидать, что интеграционное тестирование будет главным источником дефектов, будет более сложным и потребует больше времени, чем ожидалось.
Несмотря на то, что тестирование классов эквивалентности полезно, его величайшим вкладом является то, что оно приводит нас к тестированию граничных значений.
Анализ граничных значений (BVA - Boundary Value Analysis (Myers 1979)/range checking)
Тестирование классов эквивалентности - это самая основная методика тест-дизайна. Она помогает тестировщикам выбрать небольшое подмножество из всех возможных тестовых сценариев и при этом обеспечить приемлемое покрытие. У этой техники есть еще один плюс. Она приводит к идее о тестировании граничных значений - второй ключевой технике тест-дизайна.
Пример. Выше описывались правила, которые указывали, каким образом будет происходить обработка заявок на вакансии в зависимости от возраста соискателя.
Обратите внимание на проблемы на границах - это "края" каждого класса. Возраст "16" входит в два различных класса эквивалентности (как и "18", и "55"). Первое правило гласит не нанимать шестнадцатилетних. Второе правило гласит, что шестнадцатилетние могут быть наняты на неполный рабочий день Тестирование граничных значений фокусируется на границах именно потому, что там спрятано очень много дефектов. Опытные тестировщики сталкивались с этой ситуацией много раз. У неопытных тестировщиков может появиться интуитивное ощущение, что ошибки будут возникать чаще всего на границах. Эти дефекты могут быть в требованиях, или в коде, если программист ошибется с указанием границ в коде (включительно/не включительно, индекс +-1).
Попробуем исправить приведенный выше пример:
А что насчет возраста -3 и 101? Обратите внимание, что требования не указывают, как должны быть рассмотрены эти значения. Мы можем догадаться, но "угадывание требований" не является приемлемой практикой. Следующий код реализует исправленные правила:
В этом примере интересными значениями на границах или вблизи них являются {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56} и {98, 99, 100}. Другие значения, например {-42, 1001, FRED, %$#@} могут быть включены в зависимости от предусловий документации модуля.
Для создания тест-кейсов для каждого граничного значения определите классы эквивалентности, выберите одну точку на границе, одну точку чуть ниже границы и одну точку чуть выше границы. Стоит отметить, что точка чуть выше границы может входить в другой класс эквивалентности. В таком случае не нужно дублировать тест. То же самое может быть верно по отношению точки чуть ниже границы.
Тестирование граничных значений является наиболее подходящим там, где входные данные являются непрерывным диапазоном значений.
Тестирование таблиц решений (Decision Table testing)
Этот простой, но эффективный метод заключается в документировании бизнес-логики в таблице как наборы правил, условий выполнения действий и самих действий. Тестирование таблиц принятия решений может быть использовано, когда система должна реализовывать сложные бизнес-правила, когда эти правила могут быть представлены в виде комбинации условий и когда эти условия имеют дискретные действия, связанные с ними.
Пример. Компания по автострахованию дает скидку водителям, которые состоят в браке и/или хорошо учатся.
- | Правило 1 | Правило 2 | Правило 3 | Правило 4 |
Условия | - | - | - | - |
Состоит в браке? | Да | Да | Нет | Нет |
Хороший студент? | Да | Нет | Да | Нет |
- | - | - | - | - |
Действия | - | - | - | - |
Скидка ($) | 60 | 25 | 50 | 0 |
эта таблица содержит все комбинации условий. Задав два бинарных условия ("да" или "нет"), возможные комбинации будут: ("да", "да"), ("да", "нет"), ("нет", "да") и ("нет", "нет"). Каждое правило представляет собой одну из этих комбинаций. Нам, тестировщикам, нужно будет проверить, что определяются все комбинации условий. Пропущенное сочетание может привести к разработке такой системы, которая не сможет правильно обработать определенный набор исходных данных. Каждое правило является причиной "запуска" действия. Каждое правило может задать действие, уникальное для этого правила, или правила могут иметь общие действия. Для каждого правила с помощью таблицы решений можно указать более одного действия. Опять же, эти правила могут быть уникальными или быть общими. В такой ситуации выбрать тесты просто - каждое правило (вертикальная колонка) становится тест-кейсом. Условия указывают на входные значения, а действия - на ожидаемые результаты.
Если тестируемая система имеет сложные бизнес-правила, а у ваших бизнес-аналитиков или проектировщиков нет документации этих правил, то тестировщикам следует собрать эту информацию и представить ее в виде таблицы решений. Причина проста: представляя поведение системы в такой полной и компактной форме, тест-кейсы могут быть созданы непосредственно из таблицы решений. При тестировании для каждого правила создается как минимум один тест-кейс. Если состояния этого правила бинарные, то должно быть достаточно одного теста для каждого сочетания. С другой стороны, если состояние является диапазоном значений, то тестирование должно учитывать и нижнюю, и высшую границы диапазона. Таким образом мы объединяем идею тестирования граничных значений с тестированием таблиц решений.
Чтобы создать тестовую таблицу, просто измените заголовки строк и столбцов: правила станут тест-кейсами, условия входными значениями, а действия ожидаемыми результатами.
Комбинаторные техники тест-дизайна (Combination Strategies)
Тестовые примеры выбираются на основе некоторого понятия покрытия, и цель стратегии комбинирования состоит в том, чтобы выбрать тестовые примеры из набора тестов таким образом, чтобы было достигнуто 100% покрытие.
Все комбинации (All combinations): как видно из названия, этот алгоритм подразумевает генерацию всех возможных комбинаций. Это означает исчерпывающее тестирование и имеет смысл только при разумном количестве комбинаций. Например, 3 переменные с 3 значениями для каждой дают нам матрицу параметров 3х3 с 27 возможными комбинациями.
Тестирование каждого выбора (EC - Each choice testing): эта стратегия требует, чтобы каждое значение каждого параметра было включено по крайней мере в один тестовый пример (Ammann & Offutt, 1994). Это также определение 1-wise coverage.
Тестирование базового выбора (BC - Base choice testing): алгоритм стратегии комбинирования базового выбора начинается с определения одного базового тестового примера. Базовый тестовый пример может быть определен по любому критерию, включая простейший, наименьший или первый. Критерий, предложенный Амманном и Оффуттом (Ammann & Offutt, 1994), - это «наиболее вероятное значение» с точки зрения конечного пользователя. Это значение может быть определено тестировщиком или основано на рабочем профиле, если таковой существует. Из базового тестового примера создаются новые тестовые примеры, изменяя интересующие значения одного параметра за раз, сохраняя значения других параметров фиксированными в базовом тестовом примере. Базовый выбор включает каждое значение каждого параметра по крайней мере в одном тестовом примере, поэтому он удовлетворяет 1-wise coverage.
Попарное тестирование (Pairwise testing)
Pairwise testing — техника тест-дизайна, а именно метод обнаружения дефектов с использованием комбинационного метода из двух тестовых случаев. Он основан на наблюдениях о том, что большинство дефектов вызвано взаимодействием не более двух факторов (дефекты, которые возникают при взаимодействии трех и более факторов, как правило менее критичны). Следовательно, выбирается пара двух тестовых параметров, и все возможные пары этих двух параметров отправляются в качестве входных параметров для тестирования. Pairwise testing сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Захватывающей надеждой попарного тестирования является то, что путем создания и запуска 1-20% тестов вы найдете 70-85% от общего объема дефектов.
Пример: По ТЗ сайт должен работать в 8 браузерах, используя различные плагины, запускаться на различных клиентских операционных системах, получать страницы от разных веб-серверов, работать с различными серверными, операционными системами. Итого:
= 1296 комбинаций. Количество комбинаций настолько велико, что, скорее всего, у нас не хватит ресурсов, чтобы спроектировать и пройти тест-кейсы. Не следует пытаться проверить все комбинации значений для всех переменных, а нужно проверять комбинации пар значений переменных.
Использование всех пар для создания тест-кейсов основывается на двух техниках:
Подробнее с разбором примера см. у Копленда в главе 6.
На практике же вручную эти массивы никто не формирует, всю механику реализуют автоматизированные инструменты, самый популярный из них PICT. Тестировщику остается лишь подготовить и скормить данные.
Classification tree method
Дерево классификации (Classification tree): структура, показывающее иерархически упорядоченные классы эквивалентности, которое используется для разработки тестовых примеров в методе дерева классификации (Classification tree method). Не путать с Decision tree.
Метод дерева классификации: вид комбинаторной техники, в которой тестовые примеры, описанные с помощью дерева классификации, предназначены для выполнения комбинаций представителей входных и / или выходных доменов.
Чтобы рассчитать количество тестовых примеров, нам необходимо проанализировать требования, определить соответствующие тестовые функции (классификации) и их соответствующие значения (классы).
Обычно для создания Classification tree используется инструмент Classification Tree Editor. Если же взять лист бумаги и ручку, то у нас есть тестовый объект (целое приложение, определенная функция, абстрактная идея и т. д.) вверху как корень. Мы рисуем ответвления от корня как классификации (проверяем соответствующие аспекты, которые мы определили). Затем, используя классы эквивалентности и анализ граничных значений, мы определяем наши листья как классы из диапазона всех возможных значений для конкретной классификации. И если некоторые из классов могут быть классифицированы далее, мы рисуем под-ветку / классификацию с собственными листьями / классами. Когда наше дерево завершено, мы делаем проекции листьев на горизонтальной линии (Test case), используя одну из комбинаторных стратегий (all combinations, each choice и т. д.), и создаем все необходимые комбинации.
Максимальное количество тестовых примеров - это декартово произведение всех классов всех классификаций в дереве, быстро приводящее к большим числам для реалистичных тестовых задач. Минимальное количество тестовых примеров - это количество классов в классификации с наиболее содержащимися классами. На втором этапе тестовые примеры составляются путем выбора ровно одного класса из каждой классификации дерева классификации.
Тестирование переходов между состояниями (State Transition testing)
Тестирование переходов между состояниями определяется как метод тестирования ПО, при котором изменения входных условий вызывают изменения состояния в тестируемом приложении (AUT). В этом методе тестировщик предоставляет как положительные, так и негативные входные значения теста и записывает поведение системы. Это модель, на которой основаны система и тесты. Любая система, в которой вы получаете разные выходные данные для одного и того же ввода, в зависимости от того, что произошло раньше, является системой конечных состояний. Техника тестирования переходов между состояниями полезна, когда вам нужно протестировать различные системные переходы. Этот подход лучше всего подходит там, где есть возможность рассматривать всю систему как конечный автомат. Для наглядности возьмем классический пример покупки авиабилетов:
Все начинается с точки входа. Мы (клиенты) предоставляем авиакомпании информацию для бронирования. Служащий авиакомпании является интерфейсом между нами и системой бронирования авиабилетов. Он использует предоставленную нами информацию для создания бронирования. После этого наше бронирование находится в состоянии «Создано». После создания бронирования система также запускает таймер. Если время таймера истекает, а забронированный билет еще не оплачен, то система автоматически снимает бронь.
Каждое действие, выполненное над билетом, и соответствующее состояние (отмена бронирования пользователем, оплата билета, получение билета на руки, и т. д.) отображаются в блок-схеме.
На основании полученной схемы составляется набор тестов.
Определим четыре разных уровня покрытия:
Диаграмма состояний и переходов - не единственный способ документирования поведения системы. Диаграммы, возможно, легче в понимании, но таблицы состояний и переходов могут быть проще в использовании на постоянной и временной основе. Таблицы состояний и переходов состоят из четырех столбцов - "Текущее состояние", "Событие", "Действие" и "Следующее состояние". Преимущество таблицы состояний и переходов в том, что в ней перечисляются все возможные комбинации состояний и переходов, а не только допустимые. При крайне необходимом тестировании систем с высокой степенью риска, например авиационной радиоэлектротехники или медицинских устройств, может потребоваться тестирование каждой пары состояние-переход, включая те, которые не являются допустимыми. Кроме того, создание таблицы состояний и переходов часто извлекает комбинации, которые не были определены, задокументированы или рассмотрены в требованиях. Очень полезно обнаружить эти дефекты до начала кодирования.
Использование таблицы состояний и переходов может помочь обнаружить дефекты в реализации, которые позволяют недопустимые пути из одного состояния в другое. Недостатком таких таблиц является то, что, когда количество состояний и событий возрастает, они очень быстро становятся огромными. Кроме того, в таблицах, как правило, большинство клеток пустые.
Подробнее с разбором примера см. у Копленда в главе 7.
Domain testing
В главах по тестированию классов эквивалентности и граничных значений мы рассмотрели тестирование одиночных переменных, которые требовали оценки в указанных диапазонах. В этой главе мы рассмотрим тестирование нескольких переменных одновременно. Существуют две причины, по которым стоит обратить на это внимание:
Domain-тестирование - это техника, которая может применяться для определения эффективных и действенных тест-кейсов, когда несколько переменных (например, поля ввода) должны проверяться вместе - либо для эффективности, либо по причине их логического взаимодействия. Она использует и обобщает тестирование классов эквивалентности и граничных значений в n одномерных измерениях. Подобно этим техникам, мы ищем случаи, где граница была неверно определена или реализована. Несмотря на то, что эта техника лучше всего подходит для числовых значений, она может быть обобщена и на другие типы - boolean, string, enumeration и т.д.
В двухмерном измерении (с двумя взаимодействующими параметрами) могут возникнуть следующие дефекты:
Подробнее с разбором примера см. у Копленда в главе 8.
Use case-based Testing
До сих пор мы исследовали техники разработки тестовых сценариев для частей системы — входные переменные с их диапазонами и границами, бизнес-правила, представленные в виде таблиц решений, а также поведения системы, представленные с помощью диаграмм состояний и переходов. Теперь пришло время рассмотреть тестовые сценарии, которые используют системные функции с начала и до конца путем тестирования каждой из их индивидуальных операций.
Сегодня самым популярным подходом определения выполняемых системой операций является диаграмма вариантов использования (диаграмма прецедентов, Use case diagram). Как и таблицы решений и диаграммы состояний и переходов, диаграммы вариантов использования обычно создаются разработчиками для разработчиков. Но, как и другие техники, диаграммы вариантов использования содержат много полезной информации и для тестировщиков. Варианты использования были созданы Иваром Якобсоном и объяснены в его книге "Объектно-ориентированная разработка программ: подход, основанный на вариантах использования". Якобсон определил
Вариант использования (Use Case) - это сценарий, который описывает использование системы действующим лицом для достижения определенной цели (Ивар Якобсон - "Объектно-ориентированная разработка программ: подход, основанный на вариантах использования").
Прежде чем использовать сценарии для создания Test case, их необходимо подробно описать с помощью шаблона. Шаблоны могут варьироваться от проекта к проекту. Но среди таких обычных полей, как имя, цель, предварительные условия, актер (ы) и т. д., всегда есть основной успешный сценарий и так называемые расширения (плюс иногда подвариации). Расширения - это условия, которые влияют на основной сценарий успеха. А подвариации - это условия, которые не влияют на основной flow, но все же должны быть рассмотрены. После того, как шаблон заполнен данными, мы создаем конкретные Test case, используя методы эквивалентного разделения и граничных значений. Для минимального охвата нам нужен как минимум один тестовый сценарий для основного сценария успеха и как минимум один Test case для каждого расширения. Опять же, этот метод соответствует общей формуле «получите условия, которые меняют наш результат, и проверьте комбинации». Но способ получить это - проанализировать поведение Системы с помощью сценариев.
Польза вариантов использования в том, что они:
Подробнее с разбором примера см. у Копленда в главе 8.
Как создать хорошие сценарии (Сэм Канер):
Cause/Effect, Cause-Effect (CE)
Тестовые примеры должны быть разработаны так, чтобы проявлять принципы, которые характеризуют взаимосвязь между входными и выходными данными компонента, где каждый принцип соответствует единственной возможной комбинации входных данных компонента, которые были выражены как логические значения. Для каждого тестового примера следует уточнить:
Граф причинно-следственных связей (Cause-Effect Graph) использует такую модель логических взаимосвязей между причинами и следствиями для компонента. Каждая причина выражается как условие, которое может быть истинным, ложным на входе или комбинацией входных данных компонента. Каждый эффект выражается в виде логического выражения, представляющего результаты или комбинацию результатов для произошедшего компонента (?Every effect is expressed as a Boolean expression representing results, or a combination of results, for the component having occurred). Модель обычно представлена как логический граф, связывающий производные логические выражения ввода и вывода с использованием логических операторов:
Cause-Effect Graph также известен как диаграмма Исикавы, поскольку он был изобретен Каору Исикава, или как диаграмма рыбьей кости из-за того, как он выглядит.
Граф причинно-следственных связей похож на Decision Table и также использует идею объединения условий. И иногда они описываются как один метод. Но если между условиями существует много логических зависимостей, может быть проще их визуализировать на cause-effect graph.
Syntax testing
Синтаксическое тестирование используется для проверки формата и правильности входных данных в случаях символьных текстовых полей, проверки соответствия формату файла, схеме базы данных, протоколу и т.д., при этом данные могут быть формально описаны в технических или установленных и определенных обозначениях, таких как BNF (Форма Бэкуса - Наура).
Как правило, синтаксические тесты автоматизированы, так как они предполагают создание большого количества кейсов. Синтаксис тестируется с использованием двух условий:
Примечание *: Мусорные условия - это метод проверки устойчивости системы к неверным или грязным данным. Условие выполняется путем предоставления в систему грязных данных (недопустимых данных), которые не поддерживаются указанным форматом и грамматикой синтаксиса. Для создания таких данных мы определяем и применяем возможные мутации (например, отсутствующий элемент, нежелательный дополнительный элемент, недопустимое значение для элемента и т. д.) к отдельным элементам определения BNF. Затем мы разрабатываем наши кейсы, применяя мутации, которые могут давать отличительные результаты (случаи, которые приводят к действительным комбинациям, исключаются).
Check List Based Testing
Тестирование на основе контрольного списка (чеклиста) выполняется с использованием предварительно подготовленного опытными тестировщиками чеклиста, который продолжает обновляться с учетом любых новых дефектов, обнаруженных при выполнении контрольных примеров контрольного списка. При любых изменениях в продукте прогоняется быстрый чеклист, чтобы убедиться, что из-за изменений не возникло новых дефектов. Этот контрольный список не имеет отношения к пользовательским историям.
Risk-Based Testing
Тест-дизайн на основе риска можно рассмотреть как часть вида/подхода к тестированию.
Риск - это возникновение неопределенного события, которое положительно или отрицательно влияет на измеримые критерии успеха проекта. Это могут быть события, которые произошли в прошлом или текущие события, или что-то, что может произойти в будущем. Эти неопределенные события могут повлиять на стоимость, бизнес, технические и качественные цели проекта. Позитивные риски упоминаются как возможности и помощь в устойчивости бизнеса. Например, инвестирование в новый проект, изменение бизнес-процессов, разработка новых продуктов. Отрицательные риски называются угрозами, и для успеха проекта должны быть реализованы рекомендации по их минимизации или устранению.
Тестирование на основе рисков помогает обнаруживать наиболее важные и критические ошибки на ранней стадии. Это тип тестирования, основанный на вероятности риска. Он включает в себя оценку риска на основе сложности, критичности бизнеса, частоты использования, видимых областей, областей, подверженных дефектам, и т. д. Он включает определение приоритетов тестирования модулей и функций тестируемого приложения на основе влияния и вероятности отказов. Если вовремя не выявить какой-либо риск, это может помешать завершению проекта. Самым первым шагом является определение рисков, а затем их оценка, т.е. определение приоритетов, а затем обработка рисков. После того, как риски идентифицированы, необходимо оценить риск, чтобы определить риски с точки зрения их воздействия, то есть того, какой ущерб он может нанести.
Приоритет любого риска зависит от вероятности возникновения и его воздействия на продукт, то есть от того, насколько серьезным является воздействие: Priority = Probability * Severity.
Процесс Risk-based Testing:
Риск идентифицируется и анализируется, т. е. рассчитывается влияние (impact) и серьезность (severity) риска, и принимаются меры в соответствии с приоритетом риска. Как только приоритет определен, начинается тестирование, т. е. создаются объем (test scope) и план тестирования, а затем выполняется тесты.
User Journey Test
User Journey test, как следует из названия, охватывает полное путешествие пользователя по системе. Он охватывает сквозные тесты, из-за которых процент покрытия тестами больше по сравнению с другими методами. Этот метод помогает уменьшить количество тестовых примеров, поскольку тестовые примеры являются исчерпывающими и охватывают большую часть функциональности в одном сценарии. Сценарии написаны для самого сложного путешествия. Тесты взаимодействия с пользователем не связаны с пользовательскими историями (user stories).
User Story Testing (Agile)
Пользовательская история - это краткое и простое описание требований клиентов или конечного пользователя. Пользовательские истории написаны владельцем продукта (Product owner), поскольку именно он получает от клиента информацию о продукте, который будет создан. Если пользовательская история большая, она разбивается на несколько более мелких историй. Истории пользователей записываются на учетных карточках и вывешиваются на стене для обсуждения. Обсуждая важные аспекты функции, выберите те, которые в дальнейшем используются в пользовательской истории. Приемочные испытания - это заключительный этап, на котором продукт принимает заказчик после того, как он соответствует всем критериям выхода. Критерии приемлемости определяются владельцем продукта, заказчик на поставку также может привлекать разработчиков, определяя то же самое.
Exhaustive testing
Исчерпывающее тестирование (Exhaustive testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода почти всегда не представляется возможным, из-за огромного количества входных значений.
Источники:
Доп. материал:
Error Guessing;
Предположение об ошибках (EG - error guessing): Метод проектирования тестов, когда опыт тестировщика используется для предугадывания того, какие дефекты могут быть в тестируемом компоненте или системе в результате сделанных ошибок, а также для разработки тестов специально для их выявления. (ISTQB)
Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
Некоторые факторы использующиеся при Error Guessing:
Исследовательское тестирование (Exploratory testing);
См. в видах тестирования
Ad-hoc testing;
См. в видах тестирования
Attack Testing;
Атака (attack): Направленная и нацеленная попытка оценить качество, главным образом надежность, объекта тестирования за счет попыток вызвать определенные отказы. См. также негативное тестирование. (ISTQB)
Тестирование на основе атак (attack-based testing): Методика тестирования на основе опыта, использующая программные атаки с целью провоцирования отказов, в частности - отказов, связанных с защищенностью. (ISTQB)
Источник:
How Error Guessing Testing Benefit in Software Testing
Артефакт (artifact) - это один из многих видов материальных побочных продуктов, возникающих в процессе STLC. Это не только документация, а в принципе всё, что создаётся для того, чтобы быть задействованным в тестировании.
Результаты тестирования (Test Deliverables) - это артефакты, которые передаются заинтересованным сторонам проекта программного обеспечения в течение жизненного цикла разработки программного обеспечения. На каждом этапе жизненного цикла разработки программного обеспечения существуют разные результаты тестирования. Некоторые результаты тестирования предоставляются до этапа тестирования, некоторые - на этапе тестирования, а некоторые - после завершения циклов тестирования.
Наличие или отсутствие документации, ее актуальность, как и используемые виды варьируются от компании к компании и даже от проекта к проекту. Создание и ведение документации требует весомого количества времени (и компетенций), а потому важно знать основные документы и их роль в процессах, учитывать требования всех заинтересованных лиц, нормативную и законодательную базу, политику и стандарты компании и особенности проекта чтобы понимать, какие из них необходимы (и обоснованны для бизнеса) в каждом случае. Существует огромное количество вариантов документов, часть из которых вы можете никогда и не встретить в реальной работе.
По Куликову документацию можно разделить на два больших вида в зависимости от времени и места ее использования:
Можно встретить и другие классификации. Внутренняя документация подробно описывает процесс разработки продукта, например стандарты, проектную документацию, заметки о деловой переписке и т. д. Внешняя документация относится к документам, которые подробно описывают сам продукт, например, Системная документация и Пользовательская документация. К внешней документации можно отнести Test policy, Test strategy, различные отчеты, Defect Report, Замечание, Запрос на изменение (улучшение), к внутренней всё от чеклиста до плана тестирования, тестовые данные и т.п. Пользовательская документация (User documentation) - это вся документация, которая будет передана конечному пользователю в комплекте с ПО.
Виды документации:
Источник:
Доп. материал:
Политика качества - это заявления, сделанные организациями для передачи своих долгосрочных стратегических целей, задач, видения в отношении производства и поставки качественного продукта. В этих политиках излагаются основные принципы организации, которые помогают им следовать установленным процедурам при разработке и тестировании продукта и постоянно стремиться к улучшению как продукта, так и процесса. Политика в области качества отражает основные ценности организации, что помогает понять их представления об атрибуте качества, о том, что для них означает качество, подходах, ключевых областях внимания и приоритетах при обеспечении качества для своих клиентов. Наличие четко определенной политики в области качества в соответствии со стандартами ISO 9001 является обязательным требованием для организации. Quality policy составляют CEO и Quality Manager.
При написании политики подчеркиваются следующие ключевые области:
Кроме того, она должна обеспечивать прочную основу для достижения целей в области качества и периодически пересматриваться и обновляться, чтобы постоянно соответствовать существующим требованиям и ожиданиям. Вкратце можно сказать, что политика в области качества, определяемая организациями, действует как зеркало и отражает их виртуальный образ в реальном мире, на основе которого внешние организации могут воспринимать и понимать свои основные принципы и обязательства по отношению к вкладу в качество.
Политика тестирования (test policy): Документ высокого уровня, описывающий принципы, подход и основные цели организации в отношении тестирования. (ISTQB)
Политика тестирования объясняет философию тестирования компании в целом и указывает направление, которого отдел тестирования должен придерживаться и которому следует следовать. Это должно относиться как к новым проектам, так и к проектам на поддержке. Установление старшими менеджерами соответствующей политики тестирования обеспечивает прочную основу, в которой могут работать специалисты-практики. Это поможет обеспечить максимальную стратегическую ценность каждого проекта.
Политика тестирования является частью политики качества, если она есть, в таких случаях политика качества разъяснит общую цель менеджмента в отношении качества. В ином случае этот документ верхний в иерархии тестовой документации. Политика тестирования содержит следующее:
Политика тестирования также должна включать действия по тестированию, необходимые для поддержки текущего проекта, а также разработки новых проектов.
Источники:
Доп. материал:
Стратегия тестирования (test strategy): Высокоуровневое описание уровней тестирования, которые должны быть выполнены, и тестирования, входящего в эти уровни, для организации или программы из одного или более проектов. (ISTQB)
Стратегия тестирования - это статический документ высокого уровня, обычно разрабатываемый менеджером проекта. Это документ, который отражает подход к тестированию продукта и достижению целей, и дает четкое представление о том, что команда тестирования будет делать для всего проекта. Обычно он выводится из Спецификации бизнес-требований (BRS). Как только стратегия тестирования готова, группа тестирования начинает писать подробный план тестирования и продолжает дальнейшие этапы тестирования. В мире Agile некоторые компании не тратят время на подготовку плана тестирования из-за минимального времени для каждого выпуска, но они поддерживают документ стратегии тестирования. Это один из важных документов в test deliverables, которым команда тестирования делится с заинтересованными сторонами для лучшего понимания объема проекта, рисков, подходов к тестированию и других важных аспектов.
Содержание стратегии будет разным в зависимости от проекта, поэтому нет единого для всех шаблона. Можно найти эвристики в помощь, множество зарубежных статей на тему составления стратегии и некоторые общие пункты, которые чаще используются:
Источники:
Доп. материал:
“План тестирования (test plan): Документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств.” (IEEE 829)
В то время как стратегия излагает общие принципы или теорию, план детально описывает практические аспекты того, как проект будет протестирован в реальности.
Хотя есть рекомендации по составлению тест плана (IEEE 829 (1, 2), RUP), нет единственно правильного шаблона или формата для написания тест-планов. В обзорных статьях можно встретить и свои варианты:
Или:
В какой-то момент можно заметить, что все они предлагают плюс-минус похожую структуру и пункты, а итоговый вариант всё равно будет уникальным для каждого конкретного проекта. Весомая часть литературы по данной теме предполагает работу по водопадной модели разработки и эта информация не так актуальна в наше время. Это не значит, что в гибких методологиях не бывает тест-планов. Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования - по крайней мере, на высоком уровне - процесса выпуска на ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется на свет. Планирование - это непрерывное обучение, а не задача с конечным результатом.
В гибких методологиях всё чаще говорят о концепции одностраничного тест-плана, а в случае необходимости дополнений и уточнений просто создаются ссылки на внешние страницы/документы. Такой план может быть и в гугл-таблицах, в виде дашборда, mind map, и как вам самим вздумается. Тест-план призван отвечать на те вопросы, ради которых его создают. Порой весомую часть пользы от данной активности можно получить на этапе самого планирования и составления плана, а не от самого документа. Если команда понимает, что никакой практической “боли” этот документ и его создание не решает, на него нет времени, то можно прекрасно обойтись и без его формализации, т.к. в некоей словесной форме он всё равно будет существовать всегда.
“В зависимости от размеров команды, сложности продукта, количества зависимостей и строгости критериев качества эти вопросы могут быть иными. Если процесс тестирования имеет большое количество зависимостей, например разные команды должны выполнять разные этапы тестирования в строго определенном порядке - это необходимо фиксировать. Без этого ты не только не сможешь планировать работу команд, но и несколько раз выстрелишь себе в ногу, когда команды будут блокировать друг друга из-за того, что заранее не проговорили зависимости. Чем более комплексным является объект тестирования (и как результат само тестирование), тем более подробного описания требует методология тестирования, применяемые подходы и практики - просто за счёт увеличения объема того, что необходимо проверить. Без этого сложно оценивать объемы работ, давать эстимейты и строить планы по релизам. Чем более точно и строго необходимо оценивать уровень качества, тем более детально должны быть описаны критерии прохождения тестирования, ключевые метрики и quality gate`ы. Потому что без их формализации нельзя будет однозначно оценить результаты тестирования. Люди, находящиеся за пределами команды тестирования (а иногда и команды разработки в целом) хотят понимать, что вообще происходит на этапе тестирования и как обеспечивается качество продукта. Иногда это связано с регуляторикой отрасли, иногда для согласования объемов работы с заказчиком, иногда из-за высокой степени рисков или просто потому, что работа этих людей напрямую зависит от результатов процесса обеспечения качества.“ (с) Shoo and Endless Agony: What's the plan?
Виды тест-планов:
Источники:
Доп. материал:
Сценарий выполнения (test scenario): См. спецификация процедуры тестирования. (ISTQB)
Спецификация процедуры тестирования (test procedure specification): Документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования. (IEEE 829) См. также спецификация теста
Спецификация теста (test specification): Документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и/или спецификации процедуры тестирования (ISTQB)
Тестовый сценарий (Test scenario) – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им проверок корректности поведения продукта в ходе этих действий. Иными словами, это последовательность шагов, которые пользователь может предпринять, чтобы использовать ваше программное обеспечение во время тестирования. Сценарии тестирования должны учитывать все возможные способы выполнения задачи (функции) и охватывать как положительные, так и отрицательные тестовые примеры, потому что конечные пользователи могут не обязательно предпринимать шаги, которые вы от них ожидаете. Используя тестовые сценарии, мы оцениваем работу приложения с точки зрения конечного пользователя. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.
Как писать сценарии:
Не стоит путать Test scenario с Test Suite (набор тестов, тест-свит).
Набор тестов (test suite): Комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего. (ISTQB)
Test Suite - это некоторый набор формализованных Test case, объединенных между собой по общему логическому признаку, которые позволяют проверить один из частей или вариантов сценария. Test Scenario представляет собой некий пользовательский сценарий по тестированию некой функциональности. Что-то, что пользователь может захотеть сделать с вашей системой, и вы хотите это проверить. Сценарий может иметь один или несколько Test Suite.
Источники:
Доп. материал:
Тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. (IEEE 610)
Тестовый сценарий высокого уровня (high level test case): Тестовый сценарий без конкретных (уровня реализации) значений входных данных и ожидаемых результатов. Использует логические операторы, а экземпляры реальных значений еще не определены и/или доступны. (ISTQB)
Тестовый сценарий низкого уровня (low level test case): Тестовый сценарий с конкретными (уровня реализации) значениями входных данных и ожидаемых результатов. Логические операторы из тестовых сценариев высокого уровня заменяются реальными значениями, которые соответствуют целям этих логических операторов. (ISTQB)
Test case (тест-кейс, тестовый пример/случай) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части. Более строго — формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным.
Содержание тест-кейса:
В иностранной литературе часто делят кейсы на две категории:
Нужно ли вообще писать кейсы? Ответ тот же, что и для любого документа - если написание кейсов решает определенную задачу и это обоснованно, то писать. Если вы один, не путаетесь в небольшом проекте, пользуетесь чек листами/mind map/.., можете и без TMS/test runs reports наглядно предоставлять актуальные сведения о протестированности/качестве заинтересованным лицам, то не писать.
Может ли быть несколько ожидаемых результатов? Может, если это необходимо, но сразу после каждого шага.
Можно ли объединять позитивные и негативные тест-кейсы? Позитивные можно, негативные нельзя, поскольку сложно будет понять, что именно влияет на результат.
Источники:
Доп. материал:
Контрольный список/лист проверок - это список проверок, которые помогают тестировщику протестировать приложение или отдельные функции. Основная цель чеклиста состоит в том, чтобы вы не забыли проверить всё, что планировали. Классический чеклист состоит из:
Если привести простой пример из жизни, то когда вы планируете дела на день или готовитесь к важному мероприятию, вы записываете, или хотя бы составляете мысленно список дел. Это и есть пример чек-листа.
Чек-лист не обязательно является некоторой заменой тест-кейсов, это более глобальная сущность, в виде которой можно записывать множество планов и предстоящих действий: критерии начала и окончания тестирования, проверки перед началом каждой фазы, действия по их завершении, подспорье при исследовательском тестировании, накидать проверок с mind map функционала продукта, шеринг опыта с коллегами и т.п.
Разница между тест-кейсом и чек-листом
Сила тест-кейса в том, что в нем все расписано очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но создание и поддержка кейсов требует времени, сил и является рутиной. Помимо прочего, очевидно, тест-кейс часто подразумевает только один конкретный тест, когда в чек-листе подразумевается целый перечень разных проверок.
Сила чек-листа в том, что он простой. Там нет глубокой детализации, это просто памятка. К тому же, он довольно наглядный с точки зрения отчетности. Минус в том, что другому человеку может быть сложно вникнуть в суть проверок без деталей и шагов. Чек-листы стали популярнее с приходом гибких моделей разработки, когда писать детальные кейсы может не быть времени и смысла, т.к. всё меняется слишком быстро, к тому же команда может быть небольшой и расписывать кейсы просто не для кого.
Доп. материал:
Отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. (IEEE 829)
«Смысл написания отчета о проблеме (отчета об ошибке) состоит в том, чтобы исправить ошибки» - Джем Канер. Если тестировщик неправильно сообщает об ошибке, то программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима. Или потратит кучу лишнего времени на то, чтобы сделать вашу работу за вас. Едва ли такой тестировщик будет выгоден бизнесу, приятен коллегам и долго задержится на своем месте.
Главное при написании отчета - он должен быть сразу и однозначно понят читающим, а дефект однозначно воспроизведен по указанным шагам в указанном окружении.
Основные поля баг-репорта:
Дополнительные:
В случаях использования TMS поля будут настроены лидом/менеджером и в зависимости от размеров проекта могут быть пункты вроде milestone, epic, feature и т.п.
Помимо прочего, баг-репорты могут создаваться не только тестировщиками, но и любыми членами команды, приходить от пользователей или техподдержки. Во втором случае необходимо будет воспроизвести ошибку, составить баг-репорт по всем правилам или дополнить присланный, затем провести ретроспективу на тему того, как ошибка попала в прод и как этого избежать в будущем.
Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке:
Источники:
Требование (requirement): Условия или возможности, необходимые пользователю для решения определенных задач или достижения определенных целей, которые должны быть достигнуты для выполнения контракта, стандартов, спецификации, или других формальных документов. (IEEE 610)
Требования являются отправной точкой для определения того, что проектная команда будет проектировать, реализовывать и тестировать. Вне зависимости от того, какая модель разработки ПО используется на проекте, чем позже будет обнаружена проблема, тем сложнее и дороже будет ее решение. Если проблема в требованиях будет выяснена на начальной стадии, ее решение может свестись к исправлению пары слов в тексте, в то время как недоработка, вызванная пропущенной проблемой в требованиях и обнаруженная на стадии эксплуатации, может даже полностью уничтожить проект.
Источники и пути выявления требований
Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) и выявление (elicitation) осуществляются с помощью следующих основных техник:
Уровни и типы требований
Следующие требования в общем случае могут быть отнесены к нефункциональным, однако их часто выделяют в отдельные подгруппы (здесь для простоты рассмотрены лишь три таких подгруппы, но их может быть и гораздо больше; как правило, они проистекают из атрибутов качества, но высокая степень детализации позволяет отнести их к уровню требований к продукту).
Свойства качественных требований (требования к самим требованиям)
Источники требований:
Виды документов требований:
Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком совместно с Системным аналитиком. Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в следующей – и может содержать более 50 страниц;
Техники тестирования требований см. в теме “Тестирование документации” в видах тестирования.
Источники:
Доп. материал:
Пользовательская история (user story): Высокоуровневое пользовательское или бизнес-требование, обычно использующееся в гибких методологиях разработки программного обеспечения. Обычно состоит из одного или нескольких предложений на разговорном или формальном языке, описывающих функциональность, необходимую пользователю, любые нефункциональные требования и включающих в себя критерии приемки. (ISTQB)
В индустрии разработки ПО слово «требование» определяет нашу цель, что именно нужно клиентам и что заставит нашу компанию развивать свой бизнес. Будь то продуктовая компания, которая производит программные продукты, или сервисная компания, которая предлагает услуги в различных областях программного обеспечения, основной базой для всех из них является требование, а успех определяется тем, насколько хорошо эти требования выполняются. Термин «требование» имеет разные названия в разных методологиях проекта. В Waterfall это называется Requirement/Specification Document, в Agile или SCRUM требования документируются в виде «Epic» и «User Story». В модели Waterfall документы с требованиями представляют собой огромные документы на сотни страниц, поскольку весь продукт реализуется за один этап. Но это не относится к Agile / SCRUM, потому что в этих случаях требования предъявляются к небольшим функциям или фичам, поскольку продукт готовится поэтапно.
Пользовательская история определяет требования к любой функциональности или фиче, в то время как критерии приемки (Acceptance Criteria) определяют критерии готовности (Definition of done) для пользовательской истории или требования.
Пользовательская история - это требование для любой функциональности или фичи, которое записано в 1-2 строки. Пользовательская история обычно является самым простым из возможных требований и касается одной-единственной функции/фичи.
Формат:
Как /роль пользователя или клиента/, я хочу /цель, которую нужно достичь/, чтобы я мог /причина цели/.
Например, “Как пользователь WhatsApp, я хочу, чтобы значок камеры в поле ввода чата позволял захватывать и отправлять изображения, чтобы я мог щелкнуть и поделиться своими фотографиями одновременно со всеми своими друзьями.”
Это стандартный формат, но далеко не обязательный или единственно-возможный. Главное в пользовательской истории - это ценность, которую пользователь получит от функции, т.е. User Story - это приём записи требований, который помогает команде разработки понять нужду клиента и после обсуждения выбрать, описать и утвердить то решение, которое удовлетворит эту нужду.
Job Stories
В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности. Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.
“Тело” JS делится на три части:
Job Stories могут писаться по двум форматам:
Пример: When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.
Источники:
Доп. материал:
Критерии приемки (acceptance criteria): Критерии выхода, которым должны соответствовать компонент или система, для того, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом. (IEEE 610)
Критерии приемки - это условия, которым должен удовлетворять программный продукт, чтобы быть принятым пользователем, заказчиком или, в случае функциональности системного уровня, потребляющей системой. Проще говоря - это список деталей (также известных как требования) о том, как новая функция (feature) программного обеспечения должна работать / выглядеть. Это гарантирует, что:
Хорошие критерии приемки должны быть простыми для понимания, но с достаточной детализацией, чтобы убедиться, что они не слишком расплывчаты. Это не всегда универсальный подход. Но они всегда должны предоставлять достаточно информации для разработчиков, чтобы создать функцию, а для QA - для ее тестирования. Это не значит, что в процессе разработки программного обеспечения не возникнет вопросов. Но в целом функция должна быть понятной.
Формат / макет / шаблон критериев приемки (Acceptance Criteria Format/Layout/Template): существует два основных типа критериев приемки, основанные на сценариях и правилах:
Scenario-based acceptance criteria соответствует формату “Дано/Когда/Тогда” (“Given/When/Then”) (основан на BDD - behavior driven development):
Между ними в случае нескольких условий можно добавлять “И” (“AND”).
Rule-Based Acceptance Criteria - это простой список «правил» о том, как функция должна выглядеть / работать:
Хотя критерии, основанные на правилах, имеют более простой формат, нет причин, по которым они не могут быть длинными и подробными.
Кто пишет критерии приемки? Обычно в создании критериев приемки участвуют несколько человек или команд. Тем не менее, это в первую очередь делает product manager (или “product owner”). Разработчики несут ответственность за обеспечение функциональности функции, а QA - за подтверждение ее удобства использования. Но критерии приемки создаются человеком или командой, ответственной за решение, какие новые функции добавить в продукт (независимо от типа приложения или веб-сайта).
Большая часть Agile включает внесение изменений по мере развития проекта. Так могут ли критерии приемки измениться в середине спринта? Ответ: «Это зависит от обстоятельств». Если спринт начался, но разработчики еще не завершили эту функцию, можно изменить требования. Но важно всегда сначала согласовывать с разработчиками и держать других (например, QA) в курсе. Тестировщики могли написать test cases, которые больше не актуальны после изменений. Кроме того, новый объем работы может оказаться слишком большим, чтобы разработчики могли завершить его вовремя.
User Stories vs Acceptance Criteria: пользовательские истории и критерии приемки идут рука об руку. Пользовательская история описывает основную цель новой функции - обзор того, как она поможет пользователям. Критерии приемки перечисляют способы работы функции с технической точки зрения. Обычно в тикетах (например, в Jira или Trello) вверху указывается пользовательская история, за которой следуют критерии приемки
Definition of Done: чтобы заявка (или функция) считалась «выполненной», все критерии должны работать. Например, предположим, что пользовательская история была: “Как пользователь, я хочу иметь возможность войти в систему, чтобы получить доступ к панели управления моей учетной записи”. Как уже упоминалось, пользователь может войти в систему, чтобы получить доступ к панели управления своей учетной записи. Но тикет не считался бы «done», если бы он также содержал следующие критерии приемки: “Кнопка входа должна быть бирюзовой”, а фактически кнопка входа была бы, например, желтой. Иногда команда решает запустить функцию даже с незначительными несоответствиями. Таким образом, они могут пометить тикет как выполненный (или создать отдельный для решения оставшихся аспектов), даже если не все критерии работают. Но с точки зрения технического определения, это не «готово», пока не пройдут все критерии приемки.
Источник: What is Acceptance Criteria?
Отчет - это документ, содержащий информацию о выполненных действиях, результатах проведённой работы. Обычно он включает в себя таблицы, графики, списки, просто описывающую информацию в виде текста. Их пропорция и содержание определяют пользу и понятность отчета.
Нам важно понять, для кого, для чего и в каких условиях мы это делаем и на сколько это улучшит восприятие излагаемой нами информации. Надо помнить, что каждое действие преследует определенную цель. В случае отчета нам важно понять, для кого, для чего и в каких условиях мы это делаем.
Ниже перечислены наиболее известные варианты отчетов в тестировании.
Отчет по инциденту (incident report)
Отчет по инциденту (incident report): Документ, описывающий событие, которое произошло, например, во время тестирования, и которое необходимо исследовать. (IEEE 829)
Отчет об инцидентах можно определить как письменное описание инцидента, наблюдаемого во время тестирования. Чтобы лучше понять, давайте начнем с того, что такое «инцидент». Инцидент при тестировании программного обеспечения можно определить как наблюдаемое изменение или отклонение поведения системы от ожидаемого. Это может быть отклонение от функционального требования или от настроек среды. Очень часто инцидент называют дефектом или ошибкой, но это не всегда так. Инцидент - это в основном любое неожиданное поведение или реакция программного обеспечения, требующая расследования.
Инцидент необходимо расследовать, и на основании расследования инцидент может быть преобразован в дефект. Чаще всего это оказывается дефектом, но иногда это может произойти из-за различных факторов, например:
Incident report призван зафиксировать и сообщить об инциденте заинтересованным лицам, провести расследование. Составляется аналогично баг-репорту, возможно с упором на расследование, обсуждение, влияние (impact) и может быть назначен не на разработчиков для уточнения деталей.
Отчет о результатах тестирования (test result report)
Отчет о результатах тестирования - периодический отчет, в котором документируется подробная информация о выполнении теста и его результате. Также он содержит условия, предположения, ограничения теста, какой элемент теста кем тестируется. Помимо этого вносится подробная информация об оставшейся работе, чтобы показать, сколько еще работы необходимо выполнить в проекте.
Отчет о выполнении теста (Test Execution Report)
Отчет о выполнении теста содержит детали выполнения и результат выполнения теста. Обычно его готовят для отправки вышестоящему руководству от группы тестирования, чтобы показать состояние выполнения теста и ход тестирования. Когда мы доставляем программное обеспечение клиенту, мы вкратце отправим полную информацию о выполнении теста. Это даст клиенту лучшее понимание выполненного теста и покрытия.
Отчет о ходе тестирования (test progress report)
Отчет о ходе тестирования (test progress report): Документ, подводящий итог задачам и результатам, составляемый с определенной периодичностью с целью сравнения прогресса тестирования с базовой версией (например, с исходным планом тестирования) и извещения о рисках и альтернативах, требующих решения руководства. (ISTQB)
Аналитический отчет о тестировании (test evaluation report)
Аналитический отчет о тестировании (test evaluation report): Документ, создаваемый в конце процесса тестирования и подводящий итог тестовым активностям и результатам. Также в нем содержится оценка процесса тестирования и полученный опыт. (ISTQB)
Итоговый отчет о тестировании (test summary report)
Итоговый отчет о тестировании (test summary report): Документ, подводящий итог задачам и результатам тестирования, также содержащий оценку соответствующих объектов тестирования относительно критериев выхода. (IEEE 829)
Сводный отчет о тестировании содержит подробную информацию о тестировании, проведенном на протяжении жизненного цикла разработки программного обеспечения. Элементы в итоговом отчете по тестированию различаются от организации к организации, а также различаются для разных проектов. Информация в отчете об испытаниях основывается на аудитории отчета об испытаниях. Аудитория может быть клиентом, менеджментом, бизнес-аналитиком, разработчиками, членами команды тестирования, членами организации и т. д.
Отчет о пользовательском приемочном тестировании (User acceptance test report)
Отчет о пользовательском приемочном тестировании создается во время и после UAT. В нем указываются подробности проведенного пользователем приемочного теста и результат пользовательского приемочного теста. В нем также перечислены дефекты, не учтенные при UAT.
Источники:
Доп. материал:
Базис тестирования (test basis): Документ, на основании которого определяются требования к компоненту или системе. Документация, на которой базируются тестовые сценарии. Если правка данного документа может быть осуществлена только в процессе формальной процедуры внесения изменения, то такой базис тестирования называется замороженным базисом тестирования. (ISTQB)
Базис тестирования определяется как источник информации или документ, необходимый для написания кейсов, а также как данные для начала анализа тестов:
Базис тестирования должен быть четко определен и должным образом структурирован, чтобы можно было легко определить условия тестирования, из которых можно получить тестовые примеры.
Тестовое условие (test condition): Объект или событие в компоненте или системе, которое должно быть проверено одним или несколькими тестовыми наборами. Например: функция, транзакция, параметр, атрибут качества или структурный элемент. (ISTQB)
Тестовое условие - тестируемый аспект в test basis.
Источники:
Трассируемость (traceability): Способность идентифицировать связанные объекты в документации и программном обеспечении, например, требования со связанными с ними тестами. (ISTQB)
Матрица трассируемости (traceability matrix): Двумерная таблица, описывающая связь двух сущностей (например, требований и тестовых сценариев). Таблица позволяет производить прямую и обратную трассировку от одной сущности к другой, обеспечивая таким образом возможность определения покрытия и оценки влияния предполагаемых изменений. (ISTQB)
В тестировании многое можно представить в виде удобной и наглядной матрицы (таблицы): Requirement Traceability Matrix, Test matrix, Compliance Matrix, Risk Matrix, RACI Matrix и т.д.
Матрица трассируемости (Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix) используется для документирования связей между требованиями и тест-кейсами по этим требованиям и наглядного отображения трассируемости в виде простой таблицы.
Матрица трассируемости может служить одновременно в качестве матрицы покрытия. Наличие такой матрицы позволяет объективно оценить, какая часть продукта покрыта тестами, а какая нет.
Виды трассируемости:
Другой источник:
RTM актуальна на всех этапах программного проекта. Давайте разберемся с этим через водопадную модель SDLC:
При прохождении всех этих этапов трассируемость требований поддерживается с помощью этого документа. После того, как требования были внесены в таблицу, детали дизайна для этих требований будут сопоставлены с требованиями. На основе этих деталей проекта будет производиться разработка программного обеспечения / модуля. Детали репозитория кода из SVN, TFS, Bitbucket, Github будут сопоставлены. Теперь вы знаете, где находится дизайн и код каждого требования. Это трассируемость. Отслеживайте каждое требование от начала до его конечного результата по мере его использования пользователем приложения! На этапе поддержки RTM будет чрезвычайно полезен для понимания и решения проблем, пройдя через все соответствующие детали функции / требования. Улучшение функции стало бы возможным благодаря отслеживанию и пониманию логики, дизайна и кода. С точки зрения владения RTM, RTM принадлежит менеджерам проекта или бизнес-аналитикам. В организациях CMMi команда TQM также будет проверять это как стандартный результат в проектах программного обеспечения.
*Когда на основе требований к продукту составляются тест-сценарии и выполняется тестирование, это называется Requirement based testing.
Источники:
Доп. материал:
Метрика (metric): Шкала измерений и метод, используемый для измерений (ISO 14598)
“Вы не можете контролировать то, что не можете измерить” - Том Демакро.
Метрики тестирования предназначены для мониторинга и управления процессом и продуктом. Это помогает без отклонений вести проект к намеченным целям. Метрики отвечают на разные вопросы. Важно решить, на какие вопросы вы хотите получить ответы. Метрики тестирования программного обеспечения подразделяются на два типа:
Test Case Preparation Productivity = (No of Test Case) / (Effort spent for Test Case Preparation)
Test Design Coverage = ((Total number of requirements mapped to test cases) / (Total number of requirements)*100
Test Execution Productivity = (No of Test cases executed) / (Effort spent for execution of test cases)
Test Execution Coverage = (Total no. of test cases executed / Total no. of test cases planned to execute)*100
Test Cases Pass = (Total no. of test cases passed) / (Total no. of test cases executed) * 100
Test Cases Failed = (Total no. of test cases failed) / (Total no. of test cases executed) * 100
Test Cases Blocked = (Total no. of test cases blocked) / (Total no. of test cases executed) * 100
Error Discovery Rate = (Total number of defects found /Total no. of test cases executed)*100
Defect Fix Rate = (Total no of Defects reported as fixed - Total no. of defects reopened) / (Total no of Defects reported as fixed + Total no. of new Bugs due to fix)*100
Defect Density = Total no. of defects identified / Actual Size (requirements)
Defect Leakage = ((Total no. of defects found in UAT)/(Total no. of defects found before UAT)) * 100
Defect Removal Efficiency = ((Total no. of defects found pre-delivery) /( (Total no. of defects found pre-delivery )+ (Total no. of defects found post-delivery)))* 100
Источники:
Тестовый предсказатель (test oracle): Источник, при помощи которого можно определить ожидаемые результаты для сравнения с реальными результатами, выдаваемыми тестируемой системой. В роли тестового предсказателя могут выступать уже имеющаяся система (для эталонного тестирования), руководство пользователя, профессиональные знания специалиста, однако им не может быть программный код. (ISTQB)
Тестовый оракул - это механизм для определения того, прошел ли тест или нет. Использование оракулов включает сравнение (для заданных входных данных тестового примера) выходных данных тестируемой системы с выходными данными, которые, по определению оракула, должен иметь продукт. Термин «тестовый оракул» впервые был введен в статье Уильяма Э. Хаудена. Дополнительная работа над различными видами оракулов была исследована Элейн Вейкер.
Категории тестовых оракулов:
Определенные (Specified): Эти оракулы обычно связаны с формализованными подходами к моделированию программного обеспечения и построению программного кода. Они связаны с formal specification, model-based design, который может использоваться для создания тестовых оракулов, state transition specification, для которой могут быть получены оракулы, чтобы помочь model-based testing and protocol conformance testing, and design by contract, для которого эквивалентный тестовый оракул является утверждением (assertion). Указанные тестовые оракулы имеют ряд проблем. Формальная спецификация основана на абстракции, которая, в свою очередь, может иметь элемент неточности, поскольку все модели не могут зафиксировать все поведение;
Полученные (Derived): полученный тестовый оракул различает правильное и неправильное поведение, используя информацию, полученную из артефактов системы. Они могут включать в себя документацию, результаты выполнения системы и характеристики версий тестируемой системы. Regression test suites (or reports) являются примером производного тестового оракула - они построены на предположении, что результат из предыдущей версии системы может быть использован в качестве помощника (оракула) для будущей версии системы. Ранее измеренные характеристики производительности могут быть использованы в качестве оракула для будущих версий системы, например, чтобы задать вопрос о наблюдаемом потенциальном ухудшении производительности. Текстовая документация из предыдущих версий системы может использоваться в качестве основы для определения ожиданий в будущих версиях системы. Псевдо-оракул попадает в категорию полученных тестовых оракулов. Псевдо-оракул, по определению Вейукера, представляет собой отдельно написанную программу, которая может принимать те же входные данные, что и тестируемая программа или система, так что их выходные данные могут быть сопоставлены, чтобы понять, может ли быть проблема для исследования. Частичный оракул - это гибрид указанного тестового оракула и производного тестового оракула. Он определяет важные (но не полные) свойства тестируемой системы. Например, при метаморфическом тестировании (Metamorphic testing) такие свойства, называемые метаморфическими отношениями, используются при нескольких запусках системы.
Примеры:
Неявные (Implicit): Неявный тестовый оракул полагается на подразумеваемую информацию и предположения. Например, может быть какой-то подразумеваемый вывод из сбоя программы, то есть нежелательное поведение - оракул, чтобы определить, что может быть проблема. Существует несколько способов поиска и тестирования нежелательного поведения, независимо от того, называют ли это отрицательным тестированием, где есть специализированные подмножества, такие как фаззинг. У неявных тестовых оракулов есть ограничения, поскольку они полагаются на подразумеваемые выводы и предположения. Например, сбой программы или процесса может не быть приоритетной проблемой, если система является отказоустойчивой и поэтому работает в форме самовосстановления / самоуправления. Неявные тестовые оракулы могут быть подвержены ложным срабатываниям из-за зависимостей от среды;
Человек (Human): Если предыдущие категории оракулов не могут быть использованы, то потребуется участие человека. Это можно рассматривать как количественный и качественный подходы. Количественный подход направлен на поиск нужного количества информации, которую нужно собрать о тестируемой системе (например, результатов тестирования), чтобы заинтересованная сторона могла сделать решения о соответствии или выпуске программного обеспечения. Качественный подход направлен на определение репрезентативности и пригодности входных данных тестирования и контекста выходных данных тестируемой системы. Примером может служить использование реалистичных и репрезентативных данных испытаний и понимание результатов (если они реалистичны). При этом можно руководствоваться эвристическими подходами, такими как интуиция, эмпирические правила, вспомогательные контрольные списки и опыт, чтобы помочь адаптировать конкретную комбинацию, выбранную для тестируемой программы / системы.
Примеры:
Источники:
Доп. материал:
Жизненный цикл программного обеспечения (software lifecycle): Период времени, начинающийся с момента появления концепции программного обеспечения и заканчивающийся тогда, когда дальнейшее использование программного обеспечения невозможно. Жизненный цикл программного обеспечения обычно включает в себя следующие этапы: концепт, описание требований, дизайн, реализация, тестирование, инсталляция и наладка, эксплуатация и поддержка и, иногда, этап вывода из эксплуатации. Данные фазы могут накладываться друг на друга или проводиться итерационно. (ISTQB)
SDLC - это систематизированный процесс, этапы которого охватывают полный жизненный цикл программного обеспечения (Software Lifecycle) и который определяет различные этапы разработки программного обеспечения для создания высококачественного программного обеспечения, отвечающего ожиданиям клиентов и для улучшения эффективности разработки. Разработка системы должна быть завершена в заранее определенные сроки и стоимость. Каждая фаза жизненного цикла SDLC имеет свой собственный процесс и результаты, которые используются в следующей фазе.
Обычно он делится на шесть-восемь шагов, но менеджеры проектов могут объединять, декомпозировать или пропускать шаги, в зависимости от скоупа проекта.
В разных источниках фазы немного отличаются, но глобально суть везде одинакова.
Фазы SDLC:
Источники:
Доп. материал:
STLC - это процесс тестирования, который включает в себя определенную последовательность шагов, чтобы гарантировать достижение целей в области качества. В процессе STLC каждое действие выполняется планомерно и систематически. Каждый этап имеет разные цели и результаты. У разных организаций разные этапы STLC, однако основа остается прежней.
Каждая фаза STLC имеет критерии начала и окончания:
Фазы STLC
STLC имеет несколько взаимосвязанных фаз и в целом очень похож на SDLC. Эти фазы являются последовательными и называются:
Разница STLC и SDLC
STLC и SDLC тесно связаны друг с другом, но они одновременно преследуют разные задачи с одной и той же целью, а именно:
Общая цель - удовлетворение клиента и получение максимально возможного балла на этапах верификации и валидации.
Почему тестирование разбито на отдельные этапы?
Ответ из ISTQB Foundation Level Exam: У каждого этапа своя цель.
В большинстве случаев тестирование разбивается на несколько этапов в зависимости от развития самого кода и стремления к эффективному использованию ресурсов. Давайте рассмотрим пример приложения, которое включает в себя как службы REST, так и веб-интерфейс, в agile команде, которая предоставляет набор user stories, которые в конечном итоге будут развернуты как производственный выпуск.
Если команда следует Acceptance Test Driven Development (ATDD), то члены команды будут совместно работать над дизайном тестов историй. Это происходит до начала разработки (одна из характеристик ATDD). Допустим, Мэри - разработчик, который напишет код для служб REST, и допустим, что она практикует разработку через тестирование (TDD). Она строит модульные тесты, по одному, сначала позволяя тесту не пройти, а затем пишет достаточно кода для прохождения теста. Когда имеется достаточное количество тестов для удовлетворения всех требований к истории и эти тесты проходят, тогда разработка и модульное тестирование завершаются. Затем Мэри может написать автоматизированные тесты, которые включают базу данных и, возможно, другие зависимости вне ее кода. Это интеграционные тесты. Поскольку команда использует ATDD, у нее уже есть набор приемочных тестов, поэтому она основывает свои автоматизированные тесты на них. Когда код Мэри проверяется и объединяется в общую ветвь разработки, в процессе сборки выполняются автоматические регрессионные тесты, чтобы убедиться, что существующие функциональные возможности не были нарушены работой Мэри. Эти тесты часто представляют собой просто набор автоматических приемочных испытаний, проводимых в течение месяцев или лет.
Если Сэм является разработчиком пользовательского интерфейса, возможно, он также пишет модульные тесты для некоторых частей своего кода. Когда его работа будет завершена, он может также написать автоматизированные интеграционные тесты, хотя в его тестах могут отсутствовать некоторые сценарии данных, поскольку они охватываются тестами Мэри, и он больше сосредоточится на использовании самого пользовательского интерфейса. Это все еще автоматизированные приемочные тесты, но цель состоит в том, чтобы избежать излишней избыточности существующих тестовых примеров. Как и в случае с кодом Мэри, когда код Сэма проверяется и объединяется в общую ветвь, автоматически выполняется набор регрессии пользовательского интерфейса.
После того, как Сэм и Мэри закончат, Джо, QA-инженер, может провести некоторое ручное приемочное тестирование всей истории, а также некоторое исследовательское тестирование, чтобы убедиться, что сумасшедшее поведение пользователя не приводит к сумасшедшему поведению приложения. Эта комбинация автоматических и ручных тестов составляет приемочное тестирование истории. По завершении ряда историй набор изменений внедряется в интегрированную тестовую среду для окончательного тестирования. Это может представлять собой приемочное тестирование более высокого уровня, а также дополнительное регрессионное тестирование. Дополнительное приемочное тестирование может выполняться инженерами по обеспечению качества, которые следят за тем, чтобы набор историй обеспечивал согласованный рабочий процесс для пользователей и, в конечном итоге, ценность некоторых требований более высокого уровня, которые ранее были разбиты на истории.
Заключительное регрессионное тестирование проводится поверх ранее запущенного пакета автоматизированной регрессии. Возможно, это приложение имеет некоторые функции, которые просто требуют человеческого вмешательства, или, возможно, это окончательная оценка другой группы тестировщиков, которые следят за соблюдением стиля и стандартов поведения.
Как видно из этого рабочего процесса, многие из этих шагов было бы неэффективно выполнить раньше, чем когда они описаны выше. Автоматические тесты являются исключением, так как они могут и часто выполняются многократно на протяжении всего процесса. Однако большинство других «этапов» тестирования - это просто естественное развитие, основанное на развитии выпуска.
Источники:
Чтобы лучше разобраться в том, как тестирование соотносится с программированием и иными видами проектной деятельности, для начала рассмотрим самые основы — модели разработки (lifecycle model) ПО (как часть жизненного цикла (software lifecycle) ПО). При этом сразу подчеркнем, что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим именно о разработке.
Модель разработки ПО (Software Development Model, SDM) — структура, систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов. Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя выбор стратегии, расписание, необходимые ресурсы и т.д.
Знать и понимать модели разработки ПО нужно затем, чтобы уже с первых дней работы осознавать, что происходит вокруг, что, зачем и почему вы делаете. Многие начинающие тестировщики отмечают, что ощущение бессмысленности происходящего посещает их, даже если текущие задания интересны. Чем полнее вы будете представлять картину происходящего на проекте, тем яснее вам будет виден ваш собственный вклад в общее дело и смысл того, чем вы занимаетесь. Еще одна важная вещь, которую следует понимать, состоит в том, что никакая модель не является догмой или универсальным решением. Нет идеальной модели. Есть та, которая хуже или лучше подходит для конкретного проекта, конкретной команды, конкретных условий.
Водопадная модель (waterfall model) сейчас представляет скорее исторический интерес, т.к. в современных проектах практически неприменима, исключая авиастроение, военную или космическую отрасли, медицину и финансовый сектор. Она предполагает однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом. Очень упрощенно можно сказать, что в рамках этой модели в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить.
К недостаткам водопадной модели принято относить тот факт, что участие пользователей ПО в ней либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократного сбора требований. С точки зрения же тестирования эта модель плоха тем, что тестирование в явном виде появляется здесь лишь с середины развития проекта, достигая своего максимума в самом конце.
V-образная модель (V-model)
V-модель (V-model): Модель, описывающая процессы жизненного цикла разработки программного обеспечения с момента составление спецификации требований до этапа сопровождения. V модель показывает интеграцию процессов тестирования в каждую фазу цикла разработки программного обеспечения. (ISTQB)
V-образная модель (V-model) является логическим развитием водопадной. Можно заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v-образная модели жизненного цикла ПО могут содержать один и тот же набор стадий, но принципиальное отличие заключается в том, как эта информация используется в процессе реализации проекта. Очень упрощенно можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными.
Итерационная инкрементальная модель (iterative model, incremental model)
Инкрементная модель разработки (incremental development model): Модель жизненного цикла разработки, в которой проект разделен на серию приращений, каждое из которых добавляет часть функциональности в общих требованиях проекта. Требования приоритезированы и внедряются в порядке приоритетов. В некоторых (но не во всех) версиях этой модели жизненного цикла каждый подпроект следует «мини V-модели» со своими собственными фазами проектирования, кодирования и тестирования. (ISTQB)
Итеративная модель разработки (iterative development model): Модель жизненного цикла разработки, в которой проект разделен обычно на большое количество итераций. Итерация это полный цикл разработки, завершающийся выпуском (внутренним или внешним) рабочего продукта, являющегося частью конечного разрабатываемого продукта, который разрастается от итерации к итерации. (ISTQB)
Итерационная инкрементальная модель является фундаментальной основой современного подхода к разработке ПО. Ключевой особенностью данной модели является разбиение проекта на относительно небольшие промежутки (итерации), каждый из которых в общем случае может включать в себя все классические стадии, присущие водопадной и v-образной моделям. Итогом итерации является приращение (инкремент) функциональности продукта, выраженное в промежуточном билде (build).
Длина итераций может меняться в зависимости от множества факторов, однако сам принцип многократного повторения позволяет гарантировать, что и тестирование, и демонстрация продукта конечному заказчику (с получением обратной связи) будет активно применяться с самого начала и на протяжении всего времени разработки проекта. Во многих случаях допускается распараллеливание отдельных стадий внутри итерации и активная доработка с целью устранения недостатков, обнаруженных на любой из (предыдущих) стадий. Итерационная инкрементальная модель очень хорошо зарекомендовала себя на объемных и сложных проектах, выполняемых большими командами на протяжении длительных сроков. Однако к основным недостаткам этой модели часто относят высокие накладные расходы, вызванные высокой «бюрократизированностью» и общей громоздкостью модели.
Спиральная модель (spiral model)
Спиральная модель представляет собой частный случай итерационной инкрементальной модели, в котором особое внимание уделяется управлению рисками, в особенности влияющими на организацию процесса разработки проекта и контрольные точки.
Обратите внимание на то, что здесь явно выделены четыре ключевые фазы:
С точки зрения тестирования и управления качеством повышенное внимание рискам является ощутимым преимуществом при использовании спиральной модели для разработки концептуальных проектов, в которых требования естественным образом являются сложными и нестабильными (могут многократно меняться по ходу выполнения проекта).
Гибкая модель (agile model)
Гибкая методология разработки программного обеспечения (agile software development): Группа методологий разработки программного обеспечения, основанных на итеративной поэтапной разработке, где требования и решения развиваются посредством сотрудничества между самоорганизующимися межфункциональными командами. (ISTQB)
Гибкая модель представляет собой совокупность различных подходов к разработке ПО и базируется на т.н. «agile-манифесте». Положенные в основу гибкой модели подходы являются логическим развитием и продолжением всего того, что было за десятилетия создано и опробовано в водопадной, v-образной, итерационной инкрементальной, спиральной и иных моделях. Причём здесь впервые был достигнут ощутимый результат в снижении бюрократической составляющей и максимальной адаптации процесса разработки ПО к мгновенным изменениям рынка и требований заказчика.
Очень упрощенно (почти на грани допустимого) можно сказать, что гибкая модель представляет собой облегченную с точки зрения документации смесь итерационной инкрементальной и спиральной моделей; при этом следует помнить об «agile-манифесте» и всех вытекающих из него преимуществах и недостатках.
Главным недостатком гибкой модели считается сложность ее применения к крупным проектам, а также частое ошибочное внедрение ее подходов, вызванное недопониманием фундаментальных принципов модели. Тем не менее можно утверждать, что всё больше и больше проектов начинают использовать гибкую модель разработки.
В некоторых источниках можно найти еще пару моделей:
Prototype Model
Prototype Model - это модель, в которой прототип разрабатывается раньше, чем фактическое программное обеспечение. Модели-прототипы обладают ограниченными функциональными возможностями и неэффективной производительностью по сравнению с реальным программным обеспечением. Фиктивные функции используются для создания прототипов. Это ценный механизм для понимания потребностей клиентов. Внедряются отзывы, и прототип снова проверяется заказчиком на предмет любых изменений. Этот процесс продолжается до тех пор, пока модель не будет принята заказчиком. После сбора требований создается быстрый дизайн и создается прототип, который представляется заказчику для оценки. Отзывы клиентов и уточненные требования используются для модификации прототипа и снова представляются заказчику для оценки. После того, как заказчик утверждает прототип, он используется в качестве требования для создания реального программного обеспечения. Фактическое программное обеспечение построено с использованием подхода модели водопада.
Преимущества прототипа модели: Модель прототипа снижает стоимость и время разработки, так как дефекты обнаруживаются намного раньше. Отсутствующие функции или функциональные возможности или изменение требований могут быть выявлены на этапе оценки и могут быть реализованы в доработанном прототипе. Вовлечение клиента на начальном этапе уменьшает путаницу в требованиях или понимании какой-либо функциональности.
Недостатки прототипа модели: Поскольку заказчик участвует на каждом этапе, заказчик может изменить требования к конечному продукту, что увеличивает сложность объема работ и может увеличить время доставки продукта.
Модель Большого Взрыва (Big Bang Model)
Big Bang Model не имеет определенного процесса. Деньги и усилия объединяются, поскольку вход и выход представляют собой разработанный продукт, который может совпадать, а может и не совпадать с тем, что нужно заказчику. Модель Большого Взрыва не требует особого планирования и составления графиков. Разработчик выполняет анализ требований и кодирование, а также разрабатывает продукт в соответствии с его пониманием. Эта модель используется только для небольших проектов. Нет команды тестирования и формального тестирования не проводится, и это может быть причиной провала проекта.
Преимущества модели большого взрыва: Это очень простая модель. Требуется меньше планирования и составления графиков. Разработчик может создавать собственное программное обеспечение.
Недостатки модели большого взрыва: Модели Большого взрыва нельзя использовать для крупных, текущих и сложных проектов. Высокий риск и неопределенность.
Источники:
Agile - это способность создавать и реагировать на изменения. Это способ справиться с неопределенной и неспокойной средой и в конечном итоге преуспеть в ней. Авторы Agile Manifesto выбрали «Agile» в качестве названия всей этой идеи, потому что это слово олицетворяет адаптивность и реакцию на изменения, которые так важны для их подхода. На самом деле речь идет об осмыслении того, как вы можете понять, что происходит в среде, в которой вы находитесь сегодня, определить, с какой неопределенностью вы сталкиваетесь, и выяснить, как вы можете адаптироваться к этому по мере продвижения.
Гибкая разработка программного обеспечения - это больше, чем такие фреймворки, как Scrum, Extreme Programming или Feature-Driven Development (FDD). Гибкая разработка программного обеспечения - это больше, чем такие практики, как парное программирование, разработка на основе тестирования, стендапы, сессии планирования и спринты.
Гибкая разработка программного обеспечения - это общий термин для набора структур и практик, основанных на ценностях и принципах, изложенных в Манифесте гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе. Когда вы подходите к разработке программного обеспечения особым образом, обычно хорошо жить в соответствии с этими ценностями и принципами и использовать их, чтобы помочь понять, что делать в вашем конкретном контексте.
Одна вещь, которая отличает Agile от других подходов к разработке программного обеспечения, - это сосредоточение внимания на людях, выполняющих работу, и на том, как они работают вместе. Решения развиваются в результате сотрудничества между самоорганизующимися кросс-функциональными командами, использующими соответствующие методы для своего контекста. Сообщество Agile-разработчиков программного обеспечения уделяет большое внимание совместной работе и самоорганизующейся команде. Это не значит, что менеджеров нет. Это означает, что команды могут самостоятельно определять, как они собираются подходить к делу. Это означает, что эти команды кросс-функциональны. Этим командам не обязательно должны быть задействованы определенные роли, просто когда вы собираете команду вместе, вы убедитесь, что у вас есть все необходимые навыки в команде. Еще есть место для менеджеров. Менеджеры следят за тем, чтобы члены команды имели или приобрели правильный набор навыков. Менеджеры создают среду, которая позволяет команде быть успешной. Менеджеры в основном отступают и позволяют своей команде выяснить, как они собираются выпускать продукты, но они вмешиваются, когда команды пытаются, но не могут решить проблемы. Когда большинство команд и организаций начинают заниматься гибкой разработкой, они сосредотачиваются на практиках, которые помогают в совместной работе и организации работы, и это здорово. Однако другой ключевой набор практик, которым не так часто следуют, но которые должны соблюдаться, - это конкретные технические практики, которые напрямую связаны с разработкой программного обеспечения таким образом, чтобы помочь вашей команде справиться с неопределенностью. Эти технические приемы очень важны, и их нельзя упускать из виду.
В конечном итоге Agile - это образ мышления, основанный на ценностях и принципах Agile Manifesto. Эти ценности и принципы содержат указания о том, как создавать изменения и реагировать на них, а также как справляться с неопределенностью. Можно сказать, что первое предложение Agile Manifesto заключает в себе всю идею: «Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это». Когда вы сталкиваетесь с неуверенностью, попробуйте что-то, что, по вашему мнению, может сработать, получите обратную связь и внесите соответствующие коррективы. При этом помните о ценностях и принципах. Позвольте вашему контексту определять, какие рамки, практики и методы вы используете для сотрудничества со своей командой и предоставления ценности вашим клиентам.
Если Agile - это образ мышления, то что это говорит об идее Agile-методологий? Чтобы ответить на этот вопрос, вам может быть полезно иметь четкое определение методологии. Алистер Кокберн предположил, что методология - это набор условностей, которым команда соглашается следовать. Это означает, что у каждой команды будет своя собственная методология, которая будет в малой или большой степени отличаться от методологии любой другой команды. Таким образом, Agile-методологии - это условности, которым команда решает следовать в соответствии с ценностями и принципами Agile. Вы, наверное, скажете: «Подождите, - я думал, что Scrum и XP - это Agile-методологии». Алистер применил термин “framework” к этим концепциям. Они, безусловно, родились на основе методологии одной команды, но они стали фреймворками, когда были обобщены для использования другими командами. Эти фреймворки помогают понять, где команда начинает свою методологию, но они не должны быть ее методологией. Команде всегда необходимо адаптировать использование фреймворка, чтобы оно соответствовало его контексту.
Ключевые концепции Agile
The Agile Manifesto:
Основополагающие принципы Agile Manifesto:
Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto, некоторые из них:
Манифест тестирования в Agile:
Особенности тестирования в Agile
В Agile, тестирование - это ответственность каждого. Критерий качества должен соблюдаться на протяжении всего цикла. В то время как бизнес-аналитики сосредотачиваются на создании подробных пользовательских историй, разработчики сосредотачиваются на разработке качественного кода, QA несет ответственность за уточнение критериев приемлемости для каждой пользовательской истории, тестирование завершенной функциональности в каждом спринте с точки зрения клиента и проверка всей ранее выполненной функциональности. Роли и ответственность QA не ограничиваются только тестированием в Agile, но также включают в себя следующее:
Какие стратегии использует QA для проведения Agile-тестирования?
В каждой организации есть разные подходы и стратегии, которые они используют для тестирования приложений. Методология Agile предполагает подготовку документации, достаточной только для удовлетворения насущных потребностей команды. Таким образом, QA подготовят достаточно высокоуровневой документации для стратегий тестирования и планов для руководства командой. Ниже приведены несколько стратегий, которым я следую при подготовке к тестированию в Agile:
Источники:
Доп. материал:
Scrum – наиболее популярный Agile-фреймворк, для многих людей эти термины являются синонимами. Scrum - это фреймворк процесса, используемый для управления разработкой продукта и другой работой, связанной с знаниями. Скрам является эмпирическим в том смысле, что дает командам возможность установить гипотезу о том, как они думают, что что-то работает, опробовать это, проанализировать полученный опыт и внести соответствующие коррективы. То есть при правильном использовании фреймворка. Скрам структурирован таким образом, чтобы команды могли использовать практики из других фреймворков, которые имеют смысл для контекста команды.
Scrum лучше всего подходит в случае, когда кросс-функциональная команда работает в среде разработки продукта, где есть нетривиальный объем работы, которую можно разделить на более чем одну 2–4-недельную итерацию.
Ценности:
Принципы:
События:
Артефакты:
Роли:
Жизненный цикл Scrum:
Стори поинты (Story points)
Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты (1, 2). Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.
Источники:
Доп. материал:
Особенности тестирования в Scrum:
Тут и там можно встретить упоминания различных подходов к разработке и тестированию на основе чего-то, здесь краткое описание самых часто встречающихся вариантов:
Источники:
Доп. материал:
https://www.softwaretestingmaterial.com/web-application-testing-tutorial/
ВЕБ-ТЕСТИРОВАНИЕ, или тестирование веб-сайта, проверяет ваше веб-приложение или веб-сайт на наличие потенциальных ошибок, прежде чем оно будет опубликовано и доступно для широкой публики.
1. Функциональное тестирование: используется для проверки того, соответствует ли ваш продукт спецификациям, а также функциональным требованиям, которые вы наметили для него в документации по разработке. Включает в себя:
2. Юзабилити-тестирование стало важной частью любого веб-проекта. Его могут провести тестировщики или небольшая фокус-группа, похожая на целевую аудиторию веб-приложения.
3. Тестирование интерфейсов: Здесь тестируются три области: приложение, веб-сервер и сервер базы данных.
4. Тестирование базы данных: База данных является одним из важнейших компонентов вашего веб-приложения, и необходимо тщательно провести тестирование. Тестирование будет включать в себя:
5. Тестирование на совместимость. Тесты на совместимость гарантируют, что ваше веб-приложение правильно отображается на разных устройствах.
6. Тестирование производительности: Это нужно, чтобы обеспечить работу вашего сайта при любых нагрузках. Деятельность по тестированию ПО будет включать, но не ограничиваться:
7. Тестирование безопасности жизненно важно для сайта электронной коммерции, который хранит конфиденциальную информацию о клиентах, например, кредитные карты. Деятельность по тестированию будет включать:
8. Тестирование толпы (Crowd Testing): Вы берете большое количество людей (толпу) для выполнения тестов, которые в противном случае были бы выполнены выбранной группой людей в компании. Краудсорсинговое тестирование представляет собой интересную и перспективную концепцию и помогает выявить многие незамеченные дефекты. Оно включает в себя практически все типы тестирования, применимые к вашему веб-приложению.
Доп. материалы:
Ничего не забыть: универсальная схема для тестирования веб-приложений
Сектор BFSI (банковские, финансовые услуги и страхование) является крупнейшим потребителем ИТ-услуг. Банковские приложения напрямую связаны с конфиденциальными финансовыми данными. Обязательно, чтобы все операции, выполняемые банковским программным обеспечением, выполнялись без сбоев и ошибок. Банковское ПО выполняет различные функции, такие как перевод и внесение средств, запрос баланса, история транзакций, вывод средств и так далее. Тестирование банковского приложения гарантирует, что эти действия не только хорошо выполняются, но и остаются защищенными от хакеров.
Важно отметить стандартные функции, ожидаемые от любого банковского приложения:
Доп. материал:
Тестирование систем банковского ритейла
https://www.softwaretestingmaterial.com/ecommerce-testing/
Тестирование электронной коммерции помогает в предотвращении ошибок и повышает ценность продукта, обеспечивая соответствие требованиям клиента. Целями тестирования являются:
Настройка системы электронной коммерции является сложным процессом и зависит от множества рыночных переменных. Для поддержания целостности системы электронной коммерции тестирование становится обязательным. Что проверяется:
Тестирование производительности - главный приоритет в электронной коммерции. Просто задержите около 250 миллисекунд времени загрузки страницы – и это заставляет вашего клиента идти к вашему конкуренту. Гигант розничной торговли Walmart пересмотрел скорость своего сайта и заметил увеличение на 2% коэффициента конверсии посетителей и доходов на 1%. Эффективность вашего сайта зависит от этих факторов:
https://www.softwaretestingmaterial.com/payment-gateway-testing/
Платежный шлюз - это сервис приложений электронной коммерции, который принимает оплату кредитной картой для покупок в Интернете. Платежные шлюзы защищают данные кредитной карты, шифруя конфиденциальную информацию, такую как номера кредитных карт, данные владельца счета и так далее. Эта информация безопасно передается между покупателем и продавцом, и наоборот. Современные платежные шлюзы также надежно подтверждают платежи с помощью дебетовых карт, электронных банковских переводов, банковских карт, бонусных баллов и т. д.
Типы платежных систем:
Тестирование для Платежного шлюза должно включать:
Примеры тест-кейсов для тестирования платежного шлюза:
POS-тестирование определяется как тестирование приложения в точках продаж. ПО POS или Point Of Sale - это жизненно важное решение для предприятий розничной торговли, позволяющее легко совершать розничные транзакции из любого места. Вы, наверное, видели терминал торговой точки в своем любимом торговом центре. Система является более сложной, чем вы думаете, и тесно интегрирована с другими программными системами, такими как Склад, Инвентарь, Заказ на поставку, Цепочка поставок, Маркетинг, Планирование товаров и т. д. Знание предметной области POS важно для тестирования.
Оценка POS-системы может быть разбита на два уровня:
Сценарий | Кейсы |
Деятельность кассира |
|
Обработка платежного шлюза |
|
Продажи |
|
Сценарии возврата и обмена |
|
Производительность |
|
Негативные сценарии |
|
Управление акциями и скидками |
|
Отслеживание данных клиента |
|
Безопасность и соответствие нормативным требованиям |
|
Тестирование отчетности |
|
Страховые компании в значительной степени полагаются на ПО для ведения своего бизнеса. Программные системы помогают им заниматься различными видами страховой деятельности, такими как разработка стандартных форм полисов, обработка процесса выставления счетов, управление данными клиента, оказание качественных услуг клиенту, координация между филиалами и так далее. Хотя это ПО разработано с учетом ожиданий заказчика, его надежность и согласованность должны быть проверены перед его фактическим внедрением. Тестирование ПО гарантирует качество страхового ПО, выявляя ошибки перед запуском.
Страхование определяется как справедливая передача риска убытков от одного субъекта другому в обмен на платеж. Страховая компания, которая продает полис, называется СТРАХОВОЙ, а лицо или компания, которая использует полис, называется ЗАСТРАХОВАННЫЙ. Страховые полисы обычно делятся на две категории, и страховщик покупает эти полисы в соответствии с их требованиями и бюджетом. Тем не менее, есть другие виды страхования, которые подпадают под эти категории:
Есть много ветвей в страховой компании, которые требуют тестирования:
Сектор страхования представляет собой сеть небольших подразделений, которая прямо или косвенно занимается обработкой требований. Для бесперебойного функционирования страховой компании необходимо, чтобы каждое из этих подразделений было тщательно проверено для достижения желаемого результата. Тестирование включает в себя:
Образцы тестов для страховой заявки:
После перехода сектора телекоммуникаций на цифровые и компьютерные сети, телекоммуникационная отрасль повсеместно использует ПО. Сектор телекоммуникаций зависит от различных видов компонентов ПО, чтобы доставить множество услуг, таких как маршрутизация и коммутация, VoIP и широкополосный доступ, и т. д. Таким образом, тестирование ПО Telecom является неизбежным.
Для предоставления телекоммуникационных услуг требуется наличие IVR, колл-центров, выставление счетов и т. д. и системы, которые включают в себя маршрутизаторы, коммутаторы, сотовые вышки и т. д.
Примеры тест-кейсов:
Доп. материал:
Чему я научился, разрабатывая биллинговую систему
Когда компьютеры общаются друг с другом, существует общий набор правил и условий, которым должен следовать каждый компьютер. Другими словами, протоколы определяют, как данные передаются между вычислительными устройствами и по сетям.
PROTOCOL testing проверяет протоколы связи в областях коммутации, беспроводной связи, VoIP, маршрутизации и т. д. Цель состоит в том, чтобы проверить структуру пакетов, которые отправляются по сети, с помощью инструментов тестирования протоколов.
Протоколы делятся на две категории: Routed и routing. Routed могут использоваться для отправки пользовательских данных из одной сети в другую. Он переносит пользовательский трафик, такой как электронная почта, веб-трафик, передача файлов и т. д. Routed являются IP, IPX и AppleTalk.
Routing это сетевые протоколы, которые определяют маршруты для маршрутизаторов. Они используется только между маршрутизаторами. Например, RIP, IGRP, EIGRP и т. д.
Модель OSI имеет в общей сложности 7 уровней сетевого взаимодействия, в которых уровень 2 и уровень 3 очень важны.
Для тестирования протокола вам понадобится анализатор протокола и симулятор.
Анализатор протокола обеспечивает правильное декодирование наряду с анализом вызовов и сеансов. В то время как симулятор имитирует различные сущности сетевого элемента.
Обычно тестирование протокола выполняется DUT (тестируемым устройством) для других устройств, таких как коммутаторы и маршрутизаторы, и для настройки протокола в нем. После этого проверяется структура пакетов, отправленных устройствами. Он проверяет масштабируемость, производительность, алгоритм протокола и т. д. устройства с помощью таких инструментов, как lxNetworks, Scapy и Wireshark.
Тестирование протокола включает тестирование функциональности, производительности, стека протоколов, функциональной совместимости и т. д. Во время тестирования протокола, в основном, выполняется три проверки:
Тестирование протокола может быть разделено на две категории. Стресс и тесты надежности и функциональные тесты. Стресс-тесты и тесты надежности охватывают нагрузочное тестирование, стресс-тестирование, тестирование производительности и т. д. В то время как функциональное тестирование включает в себя негативное тестирование, тестирование на соответствие, тестирование на совместимость и т. д.
Тестирование соответствия: протоколы, реализованные в продуктах, тестируются на соответствие, например, IEEE, RFC и т. д. Тестирование совместимости: проверяется совместимость для разных поставщиков. Это тестирование проводится после тестирования соответствия на соответствующей платформе. Проверка функциональности сети: функциональность сетевых продуктов проверена на функциональность со ссылкой на проектную документацию. Например, функциями могут быть защита портов на коммутаторе, ACL на маршрутизаторе и т. д.
Вот примеры Test case для роутеров:
Интернет вещей - это сеть, состоящая из устройств в транспортных средствах, зданиях или любых других подключенных электронных устройств. Эта взаимосвязь облегчает сбор и обмен данными. 4 общих компонента системы IoT:
IOT - это соединение идентифицируемых встроенных устройств с существующей интернет-инфраструктурой. Проще говоря, мы можем сказать, что IOT - это эра «умных», связанных продуктов, которые обмениваются данными и передают большой объем данных и загружают их в облако.
IOT elements | Sensor | Application | Network | Backend (Data Center) |
Functional testing | True | True | False | False |
Usability testing | True | True | False | False |
Security testing | True | True | True | True |
Performance testing | False | True | True | True |
Compatibility testing | True | True | False | False |
Services testing | False | True | True | True |
Operational testing | True | True | False | False |
Категории тестов с примерами Test Conditions:
CLOUD testing - это тип тестирования программного обеспечения, который проверяет услуги облачных вычислений. Облачные вычисления - это интернет-платформа, предоставляющая различные компьютерные сервисы, такие как оборудование, программное обеспечение и другие компьютерные сервисы, удаленно. Существует три модели облачных вычислений:
Все облачное тестирование разделено на четыре основные категории:
Облачное тестирование фокусируется на основных компонентах, таких как:
Другие типы тестирования в облаке включают:
Как выполнять облачное тестирование:
Примеры Test Scenario и несколько Test case для каждого из них:
https://www.softwaretestingmaterial.com/soa-testing/
Это тестирование архитектурного стиля SOA, в котором компоненты приложения предназначены для сообщения по протоколам связи, обычно через сеть. SOA - это метод интеграции бизнес-приложений и процессов для удовлетворения потребностей бизнеса. В разработке программного обеспечения SOA обеспечивает гибкость бизнес-процессов. Изменения в процессе или приложении могут быть направлены на конкретный компонент, не затрагивая всю систему. Разработчики программного обеспечения в SOA либо разрабатывают, либо покупают куски программ под названием SERVICES. Что такое Service?
Пример: на домашней странице веб-сайта и в поисковой системе отображается ежедневный прогноз погоды. Вместо того, чтобы писать код для виджета прогноза погоды, у продавца можно купить Службу прогноза погоды и встроить ее в страницу.
Тестирование SOA должно быть сосредоточено на 3 уровнях:
Методы тестирования SOA:
https://www.softwaretestingmaterial.com/approach-the-testing-of-erp-applications/
Планирование ресурсов предприятия, также известное как ERP, представляет собой комплексное программное обеспечение, которое объединяет различные функции организации в единую систему. Программное обеспечение имеет общую базу данных, содержащую всю информацию, относящуюся к различным функциям или подразделениям организации. Система ERP помогает оптимизировать процессы и доступ к информации по всей организации 24 × 7.
Приложения ERP стали критически важными для бесперебойной работы предприятий. Поскольку они включают в себя множество модулей, функций и процессов, необходимость их проверки становится критической. Предприятия осознают необходимость использования модели SMAC (Social, Mobile, Analytics и Cloud) для ускорения роста. Однако капитальный ремонт основных процессов, администрируемых устаревшими приложениями ERP, также важен. Приложения ERP помогают предприятиям управлять различными функциями, отделами и процессами, включая генерируемые в них данные. Эти приложения помогают предприятиям работать как единое целое и в процессе генерировать такие результаты, как повышение производительности, повышение эффективности, сокращение отходов, повышение качества обслуживания клиентов и повышение рентабельности инвестиций. Ввиду важности приложений ERP для организаций, они должны быть протестированы и утверждены. Тестирование приложений ERP может обеспечить бесперебойную работу множества задач в организациях. Они могут включать в себя отслеживание инвентаризации и операций с клиентами, управление финансами и человеческими ресурсами, среди многих других.
Каждое программное обеспечение ERP поставляется с несколькими версиями и требует настройки в соответствии с конкретными бизнес-требованиями. Более того, поскольку каждый элемент приложения связан с каким-либо другим модулем, их обновление может быть сложной задачей. Например, для создания заказа на продажу потребуется доступ к модулю управления запасами. Если какой-либо из модулей не функционирует оптимально, это может повлиять на все приложение ERP. Это может оказать каскадное влияние на производительность компании, а также создать плохой опыт клиентов. Следовательно, тестирование приложений ERP должно обеспечить правильную реализацию программного обеспечения и предотвратить сбои. Тестирование программного обеспечения ERP, помимо проверки функциональности программного обеспечения, должно обеспечивать точное формирование отчетов и форм. Выявляя и устраняя ошибки на этапе тестирования, тестировщики могут избежать столкновения с проблемами после внедрения. Более того, это может привести к скорейшему внедрению программного обеспечения и обеспечить его бесперебойную работу. Службы тестирования приложений ERP проверяют бизнес-процессы, функции и регулирующие их правила. Они помогают снизить операционные риски в условиях ограниченности имеющихся ресурсов и времени.
Поскольку система ERP содержит огромные объемы данных, тестирование ручных процедур может потребовать много времени и средств. Автоматизированное тестирование может помочь проверить все функции и возможности при минимальных затратах времени и средств. Кроме того, поскольку несколько бизнес-подразделений организации могут иметь разные процессы или процедуры, автоматическое тестирование может проверять точность их результатов по конкретным параметрам. Кроме того, ERP-систему необходимо периодически обновлять с появлением новых технологий, таких как Cloud, Big Data и Mobility. Такие обновления помогают организации проверять транзакции в режиме реального времени, что невозможно вручную.
Системы ERP доступны в нескольких версиях, предназначенных для нескольких доменов, подразделений и клиентов, лучшие доступные инструменты:
Доп. материал:
Тестування CRM-систем на прикладі Salesforce
WebRTC (англ. real-time communications — коммуникации в реальном времени) - это браузерная технология, предназначенная для передачи любых потоковых данных между браузерами или приложениями с использованием технологии двухточечной передачи (point-to-point transmission). Эта технология хороша тем, что можно создать видеочат без использования стороннего сервера, она позволяет устанавливать связь между пользователями, используя только браузер. Помимо браузеров известны такие гиганты в сфере видеоконференций, как: Skype, Google Meets/hangouts, Discord.
В чем выражается качество видеосвязи? В подавляющем большинстве случаев речь о:
Как обычно пытаются тестировать? С помощью плохой сети. Например, отойти с планшетом подальше от wi-fi точки. Вообще плохая сеть подразумевает большой пинг, низкую пропускную способность канала, потерю пакетов.
К сожалению, ручное тестирование видеосвязи (впрочем, как и аудио-) не даст достоверных и точных результатов. На следующем этапе команда приходит к идее писать автотесты (по большей части unit) и лишь некоторые доходят до написания бенчмарков. Возможно, в комментариях опытные коллеги поделятся своим опытом.
Доп. материал:
ETL расшифровывается как Extract, Transform, Load. ETL - это процесс, объединяющий три этапа: извлечение, преобразование и загрузка данных из одного источника в другой. Проще говоря, операции ETL выполняются с данными, чтобы вытащить их из одной базы данных в другую. Процесс ETL часто используется в хранилищах данных.
ETL-тестирование - это тип тестирования, выполняемый для гарантии того, что данные, перенесенные из исходной в целевую базу данных, являются точными и соответствуют действующим правилам преобразования.
Пример:
Давайте рассмотрим пример слияния двух компаний - компании A и компании B. После слияния их операции будут объединены, а их клиенты, сотрудники и другие данные будут храниться в единой централизованной базе данных. Предположим, что компания A использует базу данных Oracle для хранения всей информации, а компания B использует MySQL. Теперь для объединения своей информации обе компании могут использовать процесс ETL для переноса данных из своих отдельных баз данных в одну согласованную базу данных. В процессе ETL, поскольку две базы данных различны, данные обеих компаний будут в другом формате, будут использоваться разные соглашения об именах, будут использоваться разные структуры таблиц и так далее. Из-за этих различий компаниям необходимо удостовериться, что перед загрузкой данных в целевую базу данных она была должным образом очищена и может сформировать нужный формат. При тестировании ETL тестировщики должны убедиться, что данные обеих баз данных были преобразованы в формат целевой базы данных; необходимые функции преобразования были выполнены; в процессе не было потеряно никаких данных, и данные являются точными.
Типы тестирования ETL:
Доп. материал:
«Как QA в управлении хранилища данных эволюционировал»
Как QA в управлении хранилища данных эволюционировал. Часть 2
https://tproger.ru/articles/kak-proishodit-testirovanie-vr-programmnogo-obespechenija/
https://blog.qatestlab.com/2021/04/14/how-to-test-a-messenger-app/
https://www.youtube.com/watch?v=9wpy2CwR-fU
https://martinfowler.com/articles/microservice-testing/
https://dou.ua/forums/topic/33851/
https://theqalead.com/topics/should-qas-care-about-email-testing/
Почему важно делать подтверждение e-mail при регистрации?
https://blog.qatestlab.com/2021/05/05/e-learning-software-testing/
https://m.habr.com/ru/company/otus/blog/556784/
https://habr.com/ru/company/otus/blog/557832/
https://www.softwaretestingmaterial.com/game-testing-interview-questions/
https://www.softwaretestingmaterial.com/game-testing/
+
[Forwarded from Roman (rpwheeler)]
Особняком здесь стоит тестирование в азартных играх/казино (Gambling)
Гэмблинг — это термин, который на трейдерском жаргоне означает азартное бессистемное совершение сделок, которые зачастую совершаются в состоянии потери контроля над собой. Азартная игра, гэмблинг, это не игра, основанная на навыке или причастности. Это игра, основанная на чистом шансе. Это деятельность, когда человек рискует чем-то ченным, благодаря силам случая, находящимся полностью вне его контроля или вне любого рационального ожидания.
Казино занимается "классикой" -- рулетки, карточные игры (блэкджек и другие), слоты.
Не имеют отношения к казино ("оформляются отдельно"):
- Покер и турниры по оному
- Бинго
- Бинарные опционы
Это к тому что если реально работаешь на гемблинг, то казино это одно, покер это другое, бинго это третье и бинарные опционы четвёртое (ну и ставки на спортивные состязания я забыл ещё).
[Forwarded from Roman (rpwheeler)]
К "и ещё много всего"
Во всё это (рулетку, покер, блэкджек, бинго...) может быть надо немножко уметь.
А также к вышеупомянутым играм, вебу, мобайлу и десктопу может быть веб-бэк, лайв-игры (то же казино, но с видео-трансляцией в веб или десктоп-клиент), тестирование физических слотов, изучение ограничений регулируемых рынков в разных странах и тестирование оных, бонусных и реферральных систем...
Vladislav Eremeev, [16.03.21 16:22]
[Forwarded from Roman (rpwheeler)]
Дело не только в специфике гемблинга. Разработка слота или ну пусть покер-клиента -- может и геймдев.
Но гемблинг _очень_ не сводится к разработке игр как таковых. Полно задач на тестирование фич, к играм прямого отношения не имеющих (кошельки-депозиты-бонусы-реферралы-порталы-регуляции), новых инстансов или апдейтов на эти инстансы, где подёргать игры, ну, 20% функционала. Могут попадаться задачи на тестирование времени загрузки с CDN.
Конечно, можно попасть в команду которая тестирует _только_ слоты. Но можно попасть и в команду портала, бэкенда или онлайн-кошелька, которая игр вообще не тестирует, зато им интересны SQL-запросы.
Vladislav Eremeev, [16.03.21 16:31]
[Forwarded from Ice Spirit]
Верно говоришь. Имел отношение в свое время к бекенду таких гемблинг проектов. Там от игр не было ничего от слова совсем. Апи, бд, внутренние алгоритмы, рассчеты игр и финансов. От гемблинга там было только в лучшем случае нажать кнопку чтобы запустить процесс на бекенде.
Блокче́йн - выстроенная по определённым правилам непрерывная последовательная цепочка блоков (связный список), содержащих информацию. Связь между блоками обеспечивается не только нумерацией, но и тем, что каждый блок содержит свою собственную хеш-сумму и хеш-сумму предыдущего блока. Изменение любой информации в блоке изменит его хеш-сумму. Сейчас блокчейн находит применение в таких областях, как финансовые операции, идентификация пользователей или создание технологий кибербезопасности. Блокчейн-технологии актуальны в первую очередь для банковских учреждений и государственных организаций.
https://www.softwaretestingmaterial.com/how-to-write-test-cases-for-atm/
https://www.softwaretestingmaterial.com/salesforce-testing/
https://www.softwaretestingmaterial.com/saas-testing/
Многие особенности очевидны из самого названия “мобильные” - смартфон имеет маленький дисплей, им пользуются на ходу и в условиях совместного использования с большим количеством других приложений и подключенных устройств, а высокий темп современной жизни заставит пользователя уйти к конкурентам, если экран приложения загружается дольше пары секунд, если с приложением сложно взаимодействовать или оно доставляет еще какие-либо неудобства.
Отличия от веба и десктопа:
Нативные приложения: написаны на родном для определенной платформы языке программирования. Для Android этим языком является Kotlin/Java, тогда как для iOS – objective-С или Swift. Нативные приложения находятся на самом устройстве, доступ к ним можно получить, нажав на иконку. Они устанавливаются через магазин приложений (Play Market на Android, App Store на iOS и др.). Они разработаны специально для конкретной платформы и могут использовать все возможности устройства – камеру, уведомления и т.п. (при наличии разрешений). В зависимости от предназначения нативного приложения, оно может всецело или частично обходиться без наличия интернет-соединения;
Веб-приложения: на самом деле не являются приложениями как таковыми. В сущности, они представляют собой сайты, которые адаптированы и оптимизированы под любой смартфон и выглядят похоже на нативное приложение. И для того, чтобы воспользоваться им, достаточно иметь на устройстве браузер, знать адрес и располагать интернет-соединением. Запуская мобильные веб-приложения, пользователь выполняет все те действия, которые он выполняет при переходе на любой веб-сайт, а также получает возможность «установить» их на свой рабочий стол, создав закладку страницы веб-сайта. Веб-приложения отличаются кроссплатформенностью, то есть способны функционировать, независимо от платформы девайса. Очевидным недостатком такого вида приложений является утрата работоспособности при потере интернет-соединения. Причем из этого выплывает и другой минус – их производительность, которая находится на среднем уровне, в сравнении с другими видами приложений и зависит от возможностей интернет-соединения провайдера услуг. Помимо вышеперечисленного, веб-приложения не могут получить доступ к функциям системы и самого устройства;
Гибридные приложения: это веб-приложение в обертке нативного приложения, что служит контейнером для отображения веб-приложения через встроенный упрощенный браузер (webview в Android и WKWebView в iOS). Нативный “фундамент” даёт преимущества нативных приложений: доступ к функционалу смартфона (API системы, пуши и т.п.), размещение в маркетах, иконка на рабочем столе и т.п., а сторона веб-приложений дает плюсы в виде кроссплатформенности и простоты обновления контента. Компания, имеющая веб-приложение, может практически “на коленке” собрать гибридные приложения для основных платформ и обеспечить себе присутствие в маркете и на рабочем столе клиентов;
Аналоги инсталлируемых приложений
Progressive Web Apps (PWA): термин «прогрессивное веб-приложение» не является официальным названием. Это просто сокращение, которое изначально использовалось Google для обозначения концепции создания гибкого, адаптируемого приложения с использованием только веб-технологий. PWA - это веб-приложения, которые постепенно улучшаются, чтобы функционировать как установленные нативные приложения на поддерживаемых платформах, но при этом функционируют как обычные веб-сайты в других браузерах. Качества PWA сочетают в себе лучшее из Интернета и скомпилированных приложений. PWA запускаются в браузерах, как веб-сайты. Но PWA также имеют доступ к функциям приложений; Например:
Кроссплатформенность таких веб-приложений не ограничивается мобильными устройствами. Например, на платформе Windows такие приложения тоже выглядят и существуют в системе точно также, как и нативные приложения: можно установить из стора, добавить ярлык в пуск, доступны File systems, Video, Audio, High-performance code, Databases, USB, Bluetooth и т.п., при этом все фактическое содержимое является веб-сайтом.
На самом деле, скорее всего, вы раньше часто посещали PWA, даже не осознавая этого. Если вы когда-нибудь просматривали Instagram, Pinterest, Spotify или Tinder на своем ноутбуке или смартфоне, вы столкнулись с PWA.
Таким образом, PWA имеют гораздо более низкую стоимость кроссплатформенной разработки, чем скомпилированные приложения, которым требуется определенная кодовая база для каждой платформы.
Для того, чтобы веб-приложение можно было называть PWA, оно должно соответствовать определенным критериям:
Итак, как можно ли узнать, является ли веб-сайт PWA? Ну, нет. По крайней мере, не совсем точно. Если вы не разработчик и не копаетесь в исходном коде сайта, у вас нет определенного способа точно сказать, построен ли сайт на технологии PWA. При этом есть несколько уловок, которые, хотя и не гарантируют точного результата, могут дать вам некоторые признаки того, что данный веб-сайт является PWA.
Accelerated Mobile Pages (AMP)
Accelerated Mobile Pages (AMP) – это технология с открытым исходным кодом, позволяющая создавать веб-страницы, которые быстро загружаются в мобильных браузерах. Формат AMP состоит из:
Многие воспринимают AMP как способ положить статический контент своего сайта (статьи, новости, заметки и т.д.) в кэш Google, чтобы при открытии из поиска этот контент загружался мгновенно (о высокой скорости загрузки AMP страниц свидетельствует иконка молнии в результатах поиска :)). Естественно, если вам нужно добиться именно такого результата, то с AMP это сделать будет очень легко. Но AMP — это гораздо больше чем просто технология для работы со статическим контентом или кэшем Google. AMP уже давно используется как библиотека общего назначения, основанная на web компонентах, для создания быстрых динамических страниц и даже сайтов целиком, на которые пользователи попадают как из поиска, так и из других источников, включая прямые заходы. С этой точки зрения AMP можно поставить в один ряд с Polymer, React или Angular. Естественно с оглядкой на то, что AMP предназначена для простых (чтобы это не значило) сайтов, где основной упор делается на контент, а динамическая составляющая ограничена.
Отдельно хочется отметить, что несмотря на название — Accelerated Mobile Pages, AMP может использоваться для создания любых сайтов, как десктопных, так и мобильных. Сайт проекта — ampproject.org является замечательным примером того, что можно сделать с AMP для десктопа.
Google Play Instant (Android Instant Apps (AIA))
Google Play Instant (прошлое название Android Instant Apps) - это функция, которая позволяет вам использовать приложение без необходимости полностью загружать его на свой телефон: просто найдите его в Play Store и нажмите «Открыть приложение». Более того, это позволяет вам перейти к определенному действию в приложении, которое вы не установили, просто нажав URL-адрес. Недавно Google добавил в Play Store кнопку «Попробовать» для некоторых приложений с мгновенным запуском Android.
Например, если вам прислали ссылку на видео в Buzzfeed, то можно сразу же открыть её в приложении этого сервиса, даже если оно у вас не установлено. Ранее выбор был лишь либо отдельно установить приложение, либо перейти по ссылке в браузере. Конечно, это несколько дольше, чем просто открыть веб-страницу, но всё же намного быстрее, чем устанавливать целое приложение ради одной ссылки. Обещают, что занимать весь процесс открытия чего-либо во «мгновенных приложениях» будет несколько секунд. Однако полноценную функциональность установленного приложения вы не получите, будет загружено лишь то, что необходимо для выполнения текущего действия, например, просмотра видео.
На странице часто задаваемых вопросов о приложениях Google с мгновенным запуском говорится, что эти приложения могут использовать следующие разрешения:
Все, что отсутствует в этом списке, не поддерживается Instant Apps. Обратите внимание, что такие вещи, как Bluetooth, установка будильника, использование отпечатков пальцев и установка обоев, отсутствуют.
Другие ограничения включают отсутствие поддержки фоновых служб (приложений, которые могут запускаться без ведома пользователя), push-уведомлений, доступа к внешнему хранилищу или просмотра установленных приложений на устройстве. Приложения с мгновенным запуском также не смогут изменять настройки на устройстве пользователя, такие как обои.
Ограничения на размер сборки:
Если ваша фича:
Примерами Instant Apps являются BuzzFeed, Skyscanner, Onefootball, Red Bull TV, приложение UNS ShareTheMeal, Sports.ru, Vimeo и многие другие.
Источники:
Доп. материал:
Linux Kernel
Данный уровень является базовым в архитектуре Android, так как вся система Android построена на ядре Linux с некоторыми архитектурными изменениями.
Основные задачи, выполняемые ядром: Ядро содержит в себе драйверы, необходимые для взаимодействия с оборудованием. Например, возьмем Bluetooth. В наше время сложно найти устройство, которое бы не включало в себя эту функцию. Поэтому ядро должно включать драйвер для работы с ним. На схеме выше как раз таки перечислены все драйверы, входящие в ядро Linux, поэтому не будем перечислять их все по отдельности.
Hardware Abstraction Layer (HAL)
HAL обеспечивает связь между драйверами и библиотеками. Состоит он из нескольких библиотечных модулей, каждый из которых реализует интерфейс для определенного аппаратного компонента (Bluetooth, Камера итд.). И когда к оборудованию устройства обращаются через API-интерфейс, загружается необходимый для его работы модуль.
Если объяснять на пальцах, то когда от приложения поступает какое-либо сообщение, HAL его обрабатывает таким образом, чтобы оно стало понятным для драйверов. И наоборот.
Android Runtime (ART)
Основным языком Android был выбран Java, поскольку это один из самых популярных языков программирования. Для Java существует много наработок и специалистов, а написанные на нем программы переносимы между операционными системами.
Но для того, чтобы программа работала на Java необходима виртуальная машина ‒ Java Virtual Machine. В Android используется виртуальная машина Android Runtime (ART). Эта машина специально оптимизирована для работы на мобильных устройствах: с нехваткой памяти, с постоянной выгрузкой и загрузкой приложений и т.д. В версиях Android ниже 5.0 Lollipop, использовалась виртуальная машина Dalvik - старая реализация виртуальной машины для Android.
В ART, как и в Dalvik, используется свой формат байт-кода ‒ DEX (Dalvik executable). При сборке приложения исходные файлы сначала компилируются в файлы типа class обычным компилятором, а затем конвертируются специальной утилитой в DEX.
И Dalvik, и ART оптимизируют выполняемый код, используя механизм компиляции just-in-time (JIT) - компиляция происходит во время выполнения приложения, что позволяет оптимизировать код для выполнения на конкретном устройстве. При этом байт-код приложения можно переносить на другие устройства.
ART может компилировать байт-код заранее, а не во время выполнения, используя ahead-of-time (AOT). Система сама решает, когда и какие приложения необходимо скомпилировать. Например, когда устройство не загружено и подключено к зарядке. При этом ART учитывает информацию о приложении, собранную во время предыдущих запусков, что дает дополнительную оптимизацию.
Native C/C++ Libraries
Набор библиотек, написанных на языках C или C++ и используемых различными компонентами ОС.
Примеры библиотек:
Java API Framework (Application Framework)
Набор API, написанный на языке Java и предоставляющий разработчикам доступ ко всем функциям ОС Android. Эти API-интерфейсы образуют строительные блоки, необходимые для создания приложений, упрощая повторное использование основных, модульных, системных компонентов и сервисов, таких как:
System Apps
Верхний уровень в архитектуре Android, который включает в себя ряд системных (предустановленных) приложений и тонну других приложений, которые можно скачать с Google Play.
Системные приложения на всех устройствах разные, но все они являются предустановленными производителями устройства (приложение для SMS-сообщений, календарь, карты, браузер, контакты итд.).
Этот уровень использует все уровни ниже (если смотреть на схему) для правильного функционирования приложений.
Источники:
Доп. материал:
Приложения для Android можно писать на языках Kotlin, Java и C ++. Инструменты Android SDK компилируют ваш код вместе с любыми файлами данных и ресурсов в APK или Android App Bundle.
Android package, который представляет собой архивный файл с расширением .apk, содержит содержимое приложения Android, которое требуется во время выполнения, и это файл, который устройства под управлением Android используют для установки приложения.
Пакет Android App Bundle, который представляет собой архивный файл с расширением .aab, содержит содержимое проекта приложения Android, включая некоторые дополнительные метаданные, которые не требуются во время выполнения. AAB - это формат для публикации в маркете, который нельзя установить на устройствах Android, он откладывает создание APK и подписание на более поздний этап. Например, при распространении вашего приложения через Google Play серверы Google Play генерируют оптимизированные APK-файлы, которые содержат только ресурсы и код, которые требуются конкретному устройству, запрашивающему установку приложения.
Каждое приложение Android находится в собственной изолированной программной среде безопасности или песочнице (security sandbox), защищенной следующими функциями безопасности Android:
В системе Android реализован принцип наименьших привилегий. То есть каждое приложение по умолчанию имеет доступ только к тем компонентам, которые необходимы ему для работы, и не более того. Это создает очень безопасную среду, в которой приложение не может получить доступ к частям системы, для которых у него нет разрешения. Однако есть способы для приложения обмениваться данными с другими приложениями и для приложения для доступа к системным службам:
Компоненты приложения
Компоненты приложения являются основными строительными блоками Android приложения. Каждый компонент - это точка входа, через которую система или пользователь могут войти в ваше приложение. Некоторые компоненты зависят от других. Есть четыре разных типа компонентов приложения:
Каждый тип служит определенной цели и имеет отдельный жизненный цикл, который определяет, как компонент создается и уничтожается.
Начнем разбираться с таких компонентов, как активити и фрагменты, и рассмотрим кейсы, когда система может прекратить их работу.
Активити и фрагменты (activities and fragments)
С точки зрения тестировщика, активити можно воспринимать как экран, на котором отображаются элементы. Приложение состоит, как минимум, из одной активити. По сути, активити — это контейнер для UI-компонентов. Если активити – это контейнер, то фрагменты – это UI-компоненты активити. Фрагмент тоже, в свою очередь, является контейнером для UI-компонентов. Есть классная аналогия с браузером (спасибо разработчикам!) для более наглядного представления о том, как между собой связаны активити и фрагменты. Представим, что у нас открыто несколько окон одного браузера. Это несколько активити внутри одного приложения.
Внутри окна может быть открыто несколько вкладок. Это фрагменты внутри активити.
Фрагменты работают чуть быстрее, чем активити. Но на современных устройствах разница практически неощутима. В зависимости от того, каким образом решается задача, разработчик может написать приложение только на активити или на активити с использованием фрагментов.
Операционная система при управлении жизненным циклом приложения работает именно с активити приложения. Поэтому пока нас больше всего интересует жизненный цикл активити.
Пользователи запускают большое количество приложений, а значит, создается много процессов с активити. Каждый запущенный процесс съедает оперативную память устройства, и ее становится все меньше. Но Андроид тщательно следит за процессами и в случае нехватки ресурсов для выполнения более приоритетной работы закрывает те, которые менее приоритетны. Давайте разберемся, в какой момент приложение «уязвимо» к таким решениям системы и как это может повлиять на его работоспособность.
Жизненный цикл активити
После запуска и до завершения активити всегда пребывает в одном из статусов. В тестировании нам это полезно для понимания потенциально проблемных кейсов и в контексте тестирования прерываний (Interrupt testing):
Жизненный цикл активити представлен следующими состояниями:
Теперь приведу примеры. Они покрывают основные кейсы, с которыми мы чаще всего сталкиваемся при тестировании.
Первый запуск приложения
При первом запуске приложения создается и загружается главная активити в приложении.
При переходе в состояние «Resumed» активити доступна для взаимодействия с пользователем. Все замечательно, проблем нет.
Переход с первого экрана на второй
Чтобы лучше понять, что из себя представляет состояние «Paused» давайте представим такую ситуацию: экран, поверх которого появился алерт. Мы не можем с ним взаимодействовать, но в то же время мы его видим.
Возврат со второго экрана на первый
При возврате со второго экрана на первый происходит почти то же самое, только первая активити не создается заново. Она подгружается из памяти (если, конечно, не была уничтожена системой). Вторая активити уничтожается после того, как была остановлена, так как она убирается из стека переходов.
Сворачивание и выход из приложения
При сворачивании приложения (например, по кнопке Home) активити останавливается.
Важно, чтобы при разворачивании приложения активити корректно восстановилась и данные сохранились.
На всех экранах стараемся проверять сворачивание-разворачивание приложения. Этот кейс особенно актуален на формах ввода. Согласитесь, будет обидно, если текст письма, который вы так старательно набирали, сотрется при банальном сворачивании приложения. Или форма, состоящая из множества полей, снова станет пустой.
При выходе из приложения (по аппаратной кнопке назад) помимо шага 1 и шага 2, выполняется шаг 3. Активити уничтожается и при следующем запуске приложения создается заново.
Поворот экрана
Один из значимых случаев, который плодит баги — это поворот экрана. Оказывается, при повороте экрана активити проходит полный жизненный цикл. А именно уничтожается и снова создается. И так при каждом повороте. Поэтому, опять же, проверяем поворот на каждом экране.
Поддержка горизонтальной ориентации экрана, с одной стороны, позволяет проверить корректность работы всех этапов активити, с другой стороны, значительно увеличивает количество тест-кейсов.
Многооконный режим
Начиная с Андроида 7 (с Андроида 6 как экспериментальная фича) стал доступен многооконный режим. Пользователи получили возможность видеть сразу несколько приложений на экране одновременно. При этом только то приложение, с которым пользователь сейчас взаимодействует, находится в состоянии «Resumed». Остальные устанавливаются в состояние «Paused».
Don’t keep activities (Не сохранять действия)
Надо ли проверять полный жизненный цикл активити, если приложение не поддерживает поворот экрана? Конечно, надо.
Если оперативная память давно не чистилась, ее не очень много, и в параллели с вашим приложением было запущено какое-нибудь ресурсоемкое приложение (например, Pokemon Go), то шанс, что Андроид решит «прибить» процесс с вашей активити при переключении на другое приложение, возрастает.
Как проверить корректность работы приложения вручную, если оно не поддерживает поворот экрана? Довольно просто: установить галку «don’t keep activities» в настройках разработчика и перезапустить приложение.
В этом случае эмулируется ситуация, когда памяти не хватает и Андроид уничтожает все активити, с которыми пользователь сейчас не взаимодействует, оставляя только ту, что сейчас активна.
Это не значит, что галка должна всегда быть включенной при тестировании, но периодически смотреть приложение с опцией «don’t keep activities» полезно, чтобы пользователи со слабыми устройствами не сильно страдали и не ругали нас.
Broadcast receiver (широковещательный приемник)
Для обработки внешних событий используется компонент Broadcast receiver. Приложение может подписываться на события системы и других приложений. Андроид доставляет событие приложению-подписчику, даже если оно не запущено, и таким образом, может «мотивировать» его запуск.
При тестировании нам важно понимать, какие ожидаются события и как они обрабатываются.
Например, в коде заранее было прописано, что приложение ждет сообщение от конкретного номера и имеет доступ к смс. Когда пользователю придет секретный код, то Broadcast receiver получит уведомление и в поле подтверждения операции будет введен смс-код.
Сервисы (Services)
Еще одна очень важная вещь в Андроиде — это сервисы. Они нужны для выполнения фоновых задач. При этом приложение не обязательно должно быть открыто пользователем в этот момент.
У сервисов есть несколько режимов работы. Пользователь может видеть, что сервис запущен, а может и совершенно не замечать его.
Если вы услышали волшебное слово «сервис» от разработчика, не поленитесь, выясните, какую логику работы заложили в него:
Тут основной совет при проектировании тестовых сценариев — это обдумать пользовательские кейсы, когда работа сервиса может прерваться или начать конфликтовать с работой другого сервиса. Самые коварные ситуации: когда работа сервиса начинается, а пользователь этого не ждал. В этом случае полезно выяснить, что может спровоцировать запуск сервиса.
Самые простые и безобидные — это сервисы без дополнительных параметров. При ручном тестировании мы чаще всего не замечаем их работу. Например, если нужно отправить данные в систему аналитики, то для этой задачи нередко используют именно такие сервисы.
Еще один тип сервисов это sticky-сервисы. Если работа такого сервиса внезапно завершится, то спустя какое-то время sticky-сервис «возродится». Примечательно, что с каждым разом период до «возрождения» увеличивается, чтобы он меньше мешал работе системы. В некоторых приложениях примером sticky-сервиса может быть скачивание файлов на устройство. Возможно, вы замечали, если в «шторке» сбросить закачку, то спустя какое-то время она может восстановиться и продолжить скачивать файлы.
Самые важные сервисы — те, работу которых пользователь «ощущает» на себе и она для него важна. Они называются foreground-сервисы, и у них обязательно есть нотификация в «шторке», которую пользователь не может закрыть. Система их будет уничтожать в последнюю очередь, так как приоритет у таких сервисов самый высокий.
Например, музыкальный плеер. Если свернуть приложение и даже закрыть его, то плеер продолжает играть, пока пользователь не поставит его на паузу или не закроет. Или пока другое приложение или система не приостановит его работу. В частности, для музыкального плеера вариантов может быть много: входящий звонок, другое музыкальное приложение, звуковая нотификация.
Раз речь зашла о музыкальных плеерах, то стоит отметить такое понятие, как аудиофокус.
Аудиофокус
Представим, что при запуске нескольких аудиоплееров, они все будут играть одновременно. Вряд ли это кому-то понравится. Тут на помощь приходит аудиофокус, который запрашивается приложением у системы. В случае обычного запроса аудиофокуса система как бы оповещает все запущенные приложения: «Сейчас другое приложение будет говорить, помолчите, пожалуйста». Забавно, но это происходит именно в формате просьбы.
Если ваше приложение не очень вежливое, то оно спокойно может проигнорировать запрос. Наша задача – проверять эти ситуации.
Компромиссный режим запроса аудиофокуса называется «временным перехватом аудиофокуса». Это значит, что вашему приложению вернется аудиофокус, когда прервавшее его подаст системе сигнал, что аудиофокус освобожден.
Еще один вид запроса аудиофокуса — это «duck». Он просит остальные приложения не молчать, а уменьшить громкость наполовину пока воспроизводится звук запросившего фокус приложения. Например, такой запрос используется при проигрывании звука нотификации о новом сообщении в мессенджере.
Тестирование аудиофокуса очень важно, т.к. здесь все завязано на совести разработчиков и система не принимает особого участия в разрешении конфликтов. Ну а если баг все-таки вылезет к пользователям, то не сомневайтесь, они быстро вам об этом сообщат.
На этом, пожалуй, пока можно закончить. Конечно, есть еще много деталей и нет необходимости учитывать абсолютно все при тестировании. По моему опыту, тестировщику необходимо понимать из чего состоит приложение и как оно работает. Это дает возможность анализировать непростые баги, которые возникают на пересечении бизнес-логики приложения и особенностей работы операционной системы. Особенно если дело касается Андроида.
Content providers
Поставщик контента управляет общим набором данных приложения, которые вы можете хранить в файловой системе, в базе данных SQLite, в Интернете или в любом другом постоянном хранилище, к которому ваше приложение может получить доступ. Через поставщика содержимого другие приложения могут запрашивать или изменять данные, если поставщик содержимого позволяет это. Например, система Android предоставляет поставщика контента, который управляет контактной информацией пользователя. Таким образом, любое приложение с соответствующими разрешениями может запрашивать поставщика содержимого, например ContactsContract.Data, для чтения и записи информации о конкретном человеке. Заманчиво думать о провайдере контента как о абстракции базы данных, потому что для этого распространенного случая в них встроено множество API и встроенная поддержка. Однако с точки зрения системного дизайна у них другое основное назначение. Для системы поставщик контента - это точка входа в приложение для публикации именованных элементов данных, идентифицированных схемой URI. Таким образом, приложение может решить, как оно хочет сопоставить данные, которые оно содержит, с пространством имен URI, передавая эти URI другим объектам, которые, в свою очередь, могут использовать их для доступа к данным.
Уникальный аспект системы Android заключается в том, что любое приложение может запускать компонент другого приложения. Например, если вы хотите, чтобы пользователь сделал снимок с помощью камеры устройства, вероятно, есть другое приложение, которое делает это, и ваше приложение может использовать его вместо разработки действия для самостоятельной съемки фотографии. Вам не нужно включать или даже ссылаться на код из приложения камеры. Вместо этого вы можете просто запустить действие в приложении камеры, которое делает снимок. По завершении фотография даже возвращается в ваше приложение, чтобы вы могли ее использовать. Пользователю кажется, что камера на самом деле является частью вашего приложения.
Когда система запускает компонент, она запускает процесс для этого приложения, если оно еще не запущено, и создает экземпляры классов, необходимых для компонента. Например, если ваше приложение запускает действие в приложении камеры, которое делает снимок, это действие выполняется в процессе, принадлежащем приложению камеры, а не в процессе вашего приложения. Следовательно, в отличие от приложений в большинстве других систем, приложения Android не имеют единой точки входа (нет функции main ()). Поскольку система запускает каждое приложение в отдельном процессе с правами доступа к файлам, которые ограничивают доступ к другим приложениям, ваше приложение не может напрямую активировать компонент из другого приложения. Однако система Android может. Чтобы активировать компонент в другом приложении, доставьте системе сообщение, в котором указывается ваше намерение (intent) запустить конкретный компонент. Затем система активирует компонент за вас.
Активация компонентов (Activating components)
Три из четырех типов компонентов - activities, services, and broadcast receivers - активируются асинхронным сообщением, называемым intent. Намерения связывают отдельные компоненты друг с другом во время выполнения. Вы можете думать о них как о мессенджерах, которые запрашивают действие у других компонентов, независимо от того, принадлежит ли компонент вашему приложению или другому. Намерение создается с помощью объекта Intent, который определяет сообщение для активации либо определенного компонента (explicit intent), либо определенного типа компонента (implicit intent).
Файл манифеста (The manifest file)
Прежде чем система Android сможет запустить компонент приложения, система должна знать, что компонент существует, прочитав файл манифеста приложения AndroidManifest.xml. Ваше приложение должно объявить все свои компоненты в этом файле, который должен находиться в корне каталога проекта приложения. Манифест выполняет ряд функций в дополнение к объявлению компонентов приложения, например:
Ресурсы приложения (App resources)
Приложение Android состоит из большего, чем просто кода - для него требуются ресурсы, отдельные от исходного кода, такие как изображения, аудиофайлы и все, что связано с визуальным представлением приложения. Например, вы можете определять анимацию, меню, стили, цвета и макет пользовательских интерфейсов действий с помощью файлов XML. Использование ресурсов приложения позволяет легко обновлять различные характеристики вашего приложения без изменения кода. Предоставление наборов альтернативных ресурсов позволяет оптимизировать приложение для различных конфигураций устройств, например для разных языков и размеров экрана.
Для каждого ресурса, который вы включаете в свой проект Android, инструменты сборки SDK определяют уникальный целочисленный идентификатор, который вы можете использовать для ссылки на ресурс из кода вашего приложения или из других ресурсов, определенных в XML. Например, если ваше приложение содержит файл изображения с именем logo.png (сохраненный в каталоге res / drawable /), инструменты SDK генерируют идентификатор ресурса с именем R.drawable.logo. Этот идентификатор сопоставляется с целым числом для конкретного приложения, которое вы можете использовать для ссылки на изображение и вставки его в свой пользовательский интерфейс.
Одним из наиболее важных аспектов предоставления ресурсов отдельно от исходного кода является возможность предоставления альтернативных ресурсов для различных конфигураций устройств. Например, определяя строки пользовательского интерфейса в XML, вы можете перевести строки на другие языки и сохранить эти строки в отдельных файлах. Затем Android применяет соответствующие языковые строки к вашему пользовательскому интерфейсу на основе квалификатора языка, который вы добавляете к имени каталога ресурсов (например, res / values-fr / для французских строковых значений) и языковых настроек пользователя.
Android поддерживает множество различных квалификаторов для ваших альтернативных ресурсов. Квалификатор - это короткая строка, которую вы включаете в имя своих каталогов ресурсов, чтобы определить конфигурацию устройства, для которой следует использовать эти ресурсы. Например, вы должны создать разные макеты для своих занятий в зависимости от ориентации и размера экрана устройства. Когда экран устройства находится в портретной ориентации (высокий), вы можете захотеть, чтобы макет с кнопками был вертикальным, но когда экран находится в альбомной ориентации (широкий), кнопки можно выровнять по горизонтали. Чтобы изменить макет в зависимости от ориентации, вы можете определить два разных макета и применить соответствующий квалификатор к имени каталога каждого макета. Затем система автоматически применяет соответствующий макет в зависимости от текущей ориентации устройства.
Дополнительные сведения о различных типах ресурсов, которые вы можете включить в свое приложение, и о том, как создавать альтернативные ресурсы для различных конфигураций устройств, см. В разделе «Предоставление ресурсов». Чтобы узнать больше о передовых методах разработки и разработке надежных приложений производственного качества, см. Руководство по архитектуре приложений.
Источники:
Доп. материал:
Все в курсе, что мобильные девайсы Apple работают под управлением iOS. Многие знают, что iOS представляет собой облегченную версию настольной Mac OS X. Некоторые догадываются, что в основе Mac OS X лежит POSIX-совместимая ОС Darwin, а те, кто всерьез интересуется IT, в курсе, что основа Darwin — это ядро XNU, появившееся на свет в результате слияния микроядра Mach и компонентов ядра FreeBSD. Однако все это голые факты, которые ничего не скажут нам о том, как же на самом деле работает iOS и в чем ее отличия от настольного собрата.
Mac OS X
Операционная система, установленная сегодня на все маки и (в измененном виде) на айдевайсы, ведет свою историю аж с 1988 года, который в мире IT известен также тем, что стал годом выпуска первой бета-версии операционной системы NeXTSTEP. Сама NeXTSTEP была детищем команды разработчиков Стива Джобса, который к тому времени уже покинул Apple и основал компанию NeXT, которая занялась разработкой компьютеров для образовательных нужд.
В момент своего появления на свет NeXTSTEP была поистине передовой операционной системой, которая включала в себя множество технологических новаций. В основе ОС лежало модифицированное микроядро Mach, дополненное компонентами ядра FreeBSD, включая эталонную реализацию сетевого стека. Более высокоуровневые компоненты NeXTSTEP были написаны с использованием языка Objective-C и предоставляли разработчикам приложений богатый объектно-ориентированный API. Система была снабжена развитым и весьма удобным графическим интерфейсом (ключевые компоненты которого сохранились в OS X и даже iOS) и мощной средой разработки, включавшей в себя в том числе известный всем современным разработчикам визуальный дизайнер интерфейса.
После провала NeXT и возвращения Стива Джобса в компанию Apple в 1997 году NeXTSTEP легла в основу проекта Rhapsody, в рамках которого началась разработка системы-наследника Mac OS 9. В 2000 году из Rhapsody был выделен открытый проект Darwin, исходники которого опубликованы под лицензией APSL, а уже в 2001 году появилась на свет OS X 10.0, построенная на его основе. Спустя несколько лет Darwin лег в основу операционной системы для готовящегося к выпуску смартфона, о котором до 2007-го, кроме слухов, не было известно почти ничего.
XNU и Darwin
Условно начинку OS X / iOS можно разделить на три логических уровня: ядро XNU, слой совместимости со стандартом POSIX (плюс различные системные демоны/сервисы) и слой NeXTSTEP, реализующий графический стек, фреймворк и API приложений. Darwin включает в себя первые два слоя и распространяется свободно, но только в версии для OS X. iOS-вариант, портированный на архитектуру ARM и включающий в себя некоторые доработки, полностью закрыт и распространяется только в составе прошивок для айдевайсов (судя по всему, это защита от портирования iOS на другие устройства).
По своей сути Darwin — это «голая» UNIX-подобная ОС, которая включает в себя POSIX API, шелл, набор команд и сервисов, минимально необходимых для работы системы в консольном режиме и запуска UNIX-софта. В этом плане он похож на базовую систему FreeBSD или минимальную установку какого-нибудь Arch Linux, которые позволяют запустить консольный UNIX-софт, но не имеют ни графической оболочки, ни всего необходимого для запуска серьезных графических приложений из сред GNOME или KDE.
Ключевой компонент Darwin — гибридное ядро XNU, основанное, как уже было сказано выше, на ядре Mach и компонентах ядра FreeBSD, таких как планировщик процессов, сетевой стек и виртуальная файловая система (слой VFS). В отличие от Mach и FreeBSD, ядро OS X использует собственный API драйверов, названный I/O Kit и позволяющий писать драйверы на C++, используя объектно-ориентированный подход, сильно упрощающий разработку.
iOS использует несколько измененную версию XNU, однако в силу того, что ядро iOS закрыто, сказать, что именно изменила Apple, затруднительно. Известно только, что оно собрано с другими опциями компилятора и модифицированным менеджером памяти, который учитывает небольшие объемы оперативки в мобильных устройствах. Во всем остальном это все то же XNU, которое можно найти в виде зашифрованного кеша (ядро + все драйверы/модули) в каталоге /System/Library/Caches/com.apple.kernelcaches/kernelcache на самом устройстве.
Уровнем выше ядра в Darwin располагается слой UNIX/BSD, включающий в себя набор стандартных библиотек языка си (libc, libmatch, libpthread и так далее), а также инструменты командной строки, набор шеллов (bash, tcsh и ksh) и демонов, таких как launchd и стандартный SSH-сервер. Последний, кстати, можно активировать путем правки файла /System/Library/LaunchDaemons/ssh.plist. Если, конечно, джейлбрейкнуть девайс.
На этом открытая часть ОС под названием Darwin заканчивается, и начинается слой фреймворков, которые как раз и образуют то, что мы привыкли считать OS X / iOS.
Фреймворки
Darwin реализует лишь базовую часть Mac OS / iOS, которая отвечает только за низкоуровневые функции (драйверы, запуск/остановка системы, управление сетью, изоляция приложений и так далее). Та часть системы, которая видна пользователю и приложениям, в его состав не входит и реализована в так называемых фреймворках — наборах библиотек и сервисов, которые отвечают в том числе за формирование графического окружения и высокоуровневый API для сторонних и стоковых приложений
Как и во многих других ОС, API Mac OS и iOS разделен на публичный и приватный. Сторонним приложениям доступен исключительно публичный и сильно урезанный API, однако jailbreak-приложения могут использовать и приватный.
В стандартной поставке Mac OS и iOS можно найти десятки различных фреймворков, которые отвечают за доступ к самым разным функциям ОС — от реализации адресной книги (фреймворк AddressBook) до библиотеки OpenGL (GLKit). Набор базовых фреймворков для разработки графических приложений объединен в так называемый Cocoa API, своего рода метафреймворк, позволяющий получить доступ к основным возможностям ОС. В iOS он носит имя Cocoa Touch и отличается от настольной версии ориентацией на сенсорные дисплеи.
Далеко не все фреймворки доступны в обеих ОС. Многие из них специфичны только для iOS. В качестве примеров можно привести AssetsLibrary, который отвечает за работу с фотографиями и видео, CoreBlueTooth, позволяющий получить доступ к синезубу, или iAd, предназначенный для вывода рекламных объявлений в приложениях. Другие фреймворки существуют только в настольной версии системы, однако время от времени Apple переносит те или иные части iOS в Mac OS или обратно, как, например, случилось с фреймворком CoreMedia, который изначально был доступен только в iOS.
Все стандартные системные фреймворки можно найти в системном каталоге /System/Library/Frameworks/. Каждый из них находится в своем собственном каталоге, называемом бандлом (boundle), который включает в себя ресурсы (изображения и описание элементов интерфейса), хидеры языка си, описывающие API, а также динамически загружаемую библиотеку (в формате dylib) с реализацией фреймворка.
Одна из интересных особенностей фреймворков — их версионность. Один фреймворк может иметь сразу несколько разных версий, поэтому приложение, разработанное для устаревших версий системы, будет продолжать работать, даже несмотря на изменения, внесенные в новые версии ОС. Именно так реализован механизм запуска старых iOS-приложений в iOS 7 и выше. Приложение, разработанное для iOS 6, будет выглядеть и работать именно так, как если бы оно было запущено в iOS 6.
SpringBoard
Уровнем выше находятся приложения, системные и устанавливаемые из магазина приложений. Центральное место среди них занимает, конечно же, SpringBoard (только в iOS), реализующее домашний экран (рабочий стол). Именно оно запускается первым после старта системных демонов, загрузки в память фреймворков и старта дисплейного сервера (он же менеджер композитинга, он же Quartz Compositor), отвечающего за вывод изображения на экран.
SpringBoard — это связующее звено между операционной системой и ее пользователем, графический интерфейс, позволяющий запускать приложения, переключаться между ними, просматривать уведомления и управлять некоторыми настройками системы (начиная с iOS 7). Но также это и обработчик событий, таких как касание экрана или переворот устройства. В отличие от Mac OS X, которая использует различные приложения и демоны-агенты для реализации компонентов интерфейса (Finder, Dashboard, LaunchPad и другие), в iOS почти все базовые возможности интерфейса пользователя, в том числе экран блокировки и «шторка», заключены в одном SpringBoard.
В отличие от других стоковых приложений iOS, которые располагаются в каталоге /Applications, SpringBoard наравне с дисплейным сервером считается частью фреймворков и располагается в каталоге /System/Library/CoreServices/. Для выполнения многих задач он использует плагины, которые лежат в /System/Library/SpringBoardPlugins/. Кроме всего прочего, там можно найти, например, NowPlayingArtLockScreen.lockboundle, отвечающий за отображение информации о проигрываемой композиции на экране блокировки, или IncomingCall.serviceboundle, ответственный за обработку входящего звонка.
Начиная с iOS 6 SpringBoard разделен на две части: сам рабочий стол и сервис BackBoard, ответственный за коммуникации с низкоуровневой частью ОС, работающей с оборудованием (уровень HAL). BackBoard отвечает за обработку таких событий, как касания экрана, нажатия клавиш, получение показания акселерометра, датчика положения и датчика освещенности, а также управляет запуском, приостановкой и завершением приложений.
SpringBoard и BackBoard имеют настолько большое значение для iOS, что, если каким-либо образом их остановить, вся система застынет на месте и даже запущенное в данный момент приложение не будет реагировать на касания экрана. Это отличает их от домашнего экрана Android, который является всего лишь стандартным приложением, которое можно остановить, заменить или вообще удалить из системы (в этом случае на экране останутся вполне рабочие кнопки навигации и строка состояния со «шторкой»).
Приложения
На самой вершине этой пирамиды находятся приложения. iOS различает встроенные (стоковые) высоко привилегированные приложения и сторонние, устанавливаемые из iTunes. И те и другие хранятся в системе в виде бандлов, во многом похожих на те, что используются для фреймворков. Разница заключается лишь в том, что бандл приложения включает в себя несколько иную метаинформацию, а место динамической библиотеки занимает исполняемый файл в формате Mach-O.
Стандартный каталог хранения стоковых приложений — /Applications/. В iOS он абсолютно статичный и изменяется только во время обновлений системы; пользователь получить к нему доступ не может. Сторонние приложения, устанавливаемые из iTunes, напротив, хранятся в домашнем каталоге пользователя /var/mobile/Applications/ внутри подкаталогов, имеющих вид 4-2-2-2-4, где два и четыре — это шестнадцатеричные числа. Это так называемый GUID — уникальный идентификатор, который однозначно идентифицирует приложение в системе и нужен в том числе для создания изолированной песочницы (sandbox).
Sandbox
В iOS песочницы используются для изолирования сервисов и приложений от системы и друг от друга. Каждое стороннее приложение и большинство системных работают в песочнице. С технической точки зрения песочница представляет собой классический для мира UNIX chroot, усиленный системой принудительного контроля доступа TrustedBSD MAC (модуль ядра sandbox.kext), которая отрезает приложениям не только доступ к файлам за пределами домашнего каталога, но и прямой доступ к железу и многим системным функциям ОС.
В целом заключенное в sandbox приложение ограничено в следующих возможностях:
Все эти ограничения соответствуют sandbox-профилю (набору ограничивающих правил) container и применяются к любому стороннему приложению. Для стоковых приложений, в свою очередь, могут применяться другие ограничения, более мягкие или жесткие. В качестве примера можно привести почтовый клиент (профиль MobileMail), который в целом имеет такие же серьезные ограничения, как и сторонние приложения, но может получить доступ ко всему содержимому каталога Library/. Обратная ситуация — SpringBoard, вообще не имеющий ограничений.
Внутри песочниц работают многие системные демоны, включая, например, AFC, предназначенный для работы с файловой системой устройства с ПК, но ограничивающий «область видимости» только домашним каталогом пользователя. Все доступные системные sandbox-профили располагаются в каталоге /System/Library/Sandbox/Profiles/* и представляют собой наборы правил, написанных на языке Scheme. Кроме этого, приложения также могут включать в себя дополнительные наборы правил, называемых entitlement. По сути, это все те же профили, но вшитые прямо в бинарный файл приложения (своего рода самоограничение).
Смысл существования всех этих ограничений двойной. Первая (и главная) задача, которую решает sandbox, — это защита от вредоносных приложений. Вкупе с тщательной проверкой опубликованных в iTunes приложений и запретом на запуск не подписанных цифровым ключом приложений (читай: любых, полученных не из iTunes) такой подход дает прекрасный результат и позволяет iOS находиться на вершине в списке самых защищенных от вирусов ОС.
Вторая проблема — это защита системы от самой себя и пользователя. Баги могут существовать как в стоковом софте от Apple, так и в головах юзеров. Sandbox защищает от обоих. Даже если злоумышленник найдет дыру в Safari и попытается ее эксплуатировать, он все равно останется в песочнице и не сможет навредить системе. А юзер не сможет «сломать свой любимый телефончик» и не напишет гневных отзывов в адрес Apple. К счастью, знающие люди всегда могут сделать jailbreak и обойти защиту sandbox (собственно, в этом и есть смысл джейлбрейка).
Многозадачность
Одна из самых спорных особенностей iOS — это реализация многозадачности. Она вроде бы и есть, а с другой стороны, ее нет. В сравнении с традиционными настольными ОС и пресловутым Android iOS не является многозадачной операционной системой в привычном смысле этого слова и не позволяет приложениям свободно работать в фоне. Вместо этого ОС реализует API, который приложение может использовать для выполнения отдельных задач, пока оно находится в фоновом режиме.
Впервые такой API появился в iOS 4 (до этого фоновые задачи могли выполнять только стоковые приложения) и наращивался по мере развития операционной системы. Сегодня (речь идет об iOS 7) так называемый Background API позволяет делать следующее:
Такие ограничения на работу в фоне необходимы в первую очередь для того, чтобы сохранить заряд батареи и избежать лагов интерфейса, так знакомых пользователям Android, где приложения могут делать в фоне все что захотят. На самом деле Apple настолько сильно заботится о сохранении батареи, что даже реализовала специальный механизм для группировки фоновых действий приложений и их запуска в нужные моменты, например тогда, когда смартфон активно используется, подключен к Wi-Fi-сети или к зарядному устройству.
Шесть стадий загрузки iOS
Первые четыре этапа в этой цепи образуют chain of trust, реализованный с помощью сверки цифровой подписи загружаемого компонента. Цифровую подпись имеют LLB, iBoot и ядро, что позволяет исключить внедрение в цепочку хакнутого загрузчика или ядра, которые могут быть использованы для загрузки сторонней операционной системы или джейлбрейка. Единственный способ обойти этот механизм — найти дыру в одном из загрузчиков и воспользоваться ею для обхода проверки. В свое время было найдено несколько таких дыр в Boot ROM (наиболее известен эксплойт limera1n от geohot, актуальный для iPhone 1–4), а в начале 2014 года и в iBoot (хакер iH8sn0w, эксплойт так и не был опубликован).
Удерживая кнопку «Домой» при включении iPhone, можно заставить iBoot загрузиться в так называемый режим восстановления (Recovery), который позволяет восстановить прошивку iOS или обновить ее, используя iTunes. Однако механизм автоматического OTA-обновления использует другой режим, именуемый DFU (Device Firmware Upgrade), который активируется на раннем этапе загрузки сразу после Boot ROM и реализован в двух компонентах: iBSS и iBEC. По сути, это аналоги LLB и iBoot, конечная цель которых — не загрузить ОС, а перевести смартфон в режим обновления.
Источники:
Приложения представляют очень сложное взаимодействие между вашим кодом и системными фреймворками. Системный фреймворки предоставляют базовую инфраструктуру, с которой все приложения должны работать, а вы пишете код для настройки этой инфраструктуры.
Фреймворки iOS основаны на таких шаблонах проектирования, как MVC и делегирование.
Жизненный цикл iOS приложения
Точкой входа для каждого C-приложения является функция main. Во время запуска UIApplicationMain функция устанавливает несколько ключевых объектов и запускает приложение. Сердцем каждого iOS приложения является объект UIApplication, задача которого — облегчить взаимодействие между системой и другими объектами приложения. Рисунок ниже показывает объекты, обычно встречающиеся в iOS приложениях. А еще ниже представлено описание роли каждого объекта в приложении. Первое что стоит отметить — iOS приложения используют архитектуру Model-View-Controller. Эта архитектура имеет решающее значение для создания приложений, которые могут работать на различных устройствах с различными размерами экрана.
Приложение в главном цикле обрабатывает все пользовательские события. Главный цикл работает в главном потоке приложения. На изображении ниже показана схема работы главного цикла.
В любой момент времени ваши приложение находятся в каком либо из перечисленных ниже состояний. Система меняет состояния вашего приложения в ответ на происходящие события. Например, когда пользователь нажимает кнопку Home, или поступает входящий вызов, или что либо еще — приложения в ответ на все это меняют свое состояние.
Большинство переходов между состояниями обеспечивается соответствующими методами в AppDelegate.
Приложение должно быть готово к завершению в любое время. Завершение — это нормальная часть жизненного цикла. Система обычно выключает приложения, для очищения памяти и подготовки к запуску других приложений, которые запущены пользователем, но система также может выключить приложения , которые некорректно или не отвечающим на события своевременно.
Suspended приложения не получают уведомления о завершении. Система убивает процесс и восстанавливает соответствующую память. Если приложение запущено в фоне и не отвечает, система вызовет applicationWillTerminate: чтобы приложение подготовилось к выключению. Система не вызывает метод когда устройство перезагружается.
Система создает приложение в основном потоке и вы можете создавать отдельные потоки, если вам это необходимо, для решения каких либо задач. Для приложений iOS, предпочтительным методом является использование Grand Central Dispatch (GCD), оперирующим с объектами, и другими интерфейсами асинхронного программирования не создавая и управляя потоками собственноручно. Такие технологии как GCD позволяют определить работу, которую вы хотите сделать и в каком порядке вы хотите ее сделать, но пусть система решает как лучше выполнить эту работу для CPU. Когда система управляет вашими потоками вам становиться легче писать код, обеспечивается большая корректность кода, а так же увеличивает общую производительность.
Источники:
Доп. материал:
В настройках обеих платформ скрыто меню разработчика с полезными возможностями.
Информации по меню в iOS почти никакой, нашел лишь упоминание таких пунктов:
Android developer options:
Источники:
Последние годы обе системы заимствовали что-то друг у друга и пользовательский опыт теперь у них мало чем отличается, тем не менее, различий всё ещё хватает в другом:
Источники:
Доп. материал:
Актуализируется перед собеседованием, т.к. написанное здесь будет слишком быстро устаревать.
В описанный ниже чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению. Чек-лист состоит из восьми разделов:
Функциональное тестирование: В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Тестирование совместимости: Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Тестирование безопасности: Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Тестирование локализации и глобализации: Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Стрессовое тестирование: Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Кросс-платформенное тестирование: Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Тестирование производительности: Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Помимо прочего, можно использовать эвристики и мнемоники: I SLICED UP FUN, COP FLUNG GUN, SFDPOT, LONG FUN CUP.
Источники:
Доп. материал:
Android:
iOS:
Реальное устройство: позволяет запускать мобильные приложения и проверять его функциональность. Тестирование реального устройства гарантирует, что ваше приложение будет работать без проблем на клиентских телефонах. Когда устройств становится слишком много, их иногда собирают в так называемые фермы устройств. Реальными устройствами также не обязательно обладать, сейчас широко распространены облачные решения.
Эмулятор: пытается дублировать устройство - это полноценная виртуалка (контейнер) со своей сетевой картой и диском, то есть представляет собой полную повторную реализацию конкретного устройства или платформы изолированно внутри нашей хост-системы. Одним из недостатков такого подхода является скорость работы. Примером служит эмулятор в Android Studio, хотя можно найти и неофициальные образы Android-устройств.
Симулятор: пытается дублировать только поведение устройства. Как правило, симулятор - это имитация лишь отдельных свойств, возможностей или функций симулируемой системы, причем не в полном объеме, а только в том, в каком это необходимо в рамках тех задач, которые были поставлены перед симулятором. Вы как будто бы работаете с настоящим устройством, но при этом под капотом оно является лишь ПО-имитацией, не работающей изолированно от нашей системы и использующей общий диск и сеть. Примером служит симулятор в XCode.
Push-уведомления — это сообщения, отправляемые приложением на мобильное устройство клиента. Они обычно используются для доставки обновлений продуктов, напоминаний, персонализированных предложений, последних новостей и любой информации, которая является неотъемлемой частью функциональности приложения и требует особого внимания или быстрых действий.
Принцип работы push-уведомлений
В случае iOS уведомления работают через облачную платформу APNS (Apple Push Notification Service).
Если говорить о решении пуш-уведомлений от Android, то есть несколько вариантов. Самый простой способ действовать — использовать Firebase Cloud Messaging (для устройств Android с Google Apps). Если у ваших пользователей есть устройства Huawei (а именно, без Google Apps), вам следует прибегнуть к Huawei Push Kit.
Конечно, вы также можете создать собственного провайдера push-уведомлений или использовать готовые проекты, поскольку платформа имеет открытый исходный код.
Разница между push-уведомлениями в iOS и Android
Функции push-уведомлений в iOS и Android довольно сильно различаются.
iOS основана на модели push Opt-In, которая не позволяет брендам отправлять мобильные push-уведомления пользователям своих приложений до тех пор, пока эти пользователи не согласятся их получать. Android, с другой стороны, автоматически разрешает пользователям получать push-уведомления с возможностью отказаться от них вручную.
Подход Android по сравнению с iOS по умолчанию дает более широкую аудиторию пользователей с поддержкой push. Однако, когда у пользователей нет возможности легко отказаться от их получения, нерелевантные или слишком частые уведомления могут подтолкнуть клиентов отключить сообщения или удалить приложение.
Тестирование push-уведомлений
Не приходят push-уведомления: Чтобы разобраться в причине, для начала проверьте, чтобы в меню устройства была активирована соответствующая функция (разрешены уведомления для конкретного приложения). Затем убедитесь, что не включен режим «Не беспокоить». Если всё настроено правильно, но уведомления не приходят, попробуйте перезагрузить устройство и заново авторизоваться в приложении. Бывает так, что необходимо заново отправить push-токен на серверную часть сервиса. Проверьте также, какой стиль уведомления используется (необходим «Баннер» либо «Предупреждение»). Если не помогло всё перечисленное, попробуйте перезайти в свою учетную запись магазина приложений, либо откройте саму программу, в том случае, если на другие приложения тоже не приходят push-уведомления (стоит также проверить наличие интернета на устройстве).
Переходы по push-уведомлению: При тестировании необходимо проверить такие сценарии (с учётом того, что пользователь может быть авторизован или неавторизован):
Существуют push-уведомления, которые ведут на определенный экран с выбором определенных фильтров. В таком случае необходимо проверить, что переход осуществляется на правильный экран. Если это был поисковой запрос, то проверьте, что текст поискового запроса отображается в строке поиска и выдача товаров соответствует поиску. Также могут передаваться определенные фильтры, в таком случае необходимо проверить, что выбраны все «зашитые» фильтры.
Если push-уведомление ведет на WebView, то проверьте, что WebView открывается корректно на обеих платформах. И что в push зашит корректный URL.
Устаревший push-токен: У устройства изменился push-токен, когда восстановили приложение из резервной копии системы и не передался новый push-токен.
Очередь со стороны Apple: В Apple большая очередь на отправку push-уведомлений, они приходят с задержкой (Apple не гарантирует доставку push).
Проверка максимального и минимального количества отображаемых символов: В iOS и Android имеется лимит отображаемых символов. Он разный. Максимальное значение количества символов для платформы iOS – ограничение в 4 строки (178 символов), а для Android – не более 13 строк (663 символа). Не забудьте также проверить push-уведомление, содержащее минимальное количество символов, для обоих платформ можно задать 1 символ.
Кастомный звук для push-уведомления: При тестировании push-уведомлений важно учитывать тот факт, что звук push-уведомления может быть задан кастомный. В таком случае необходимо проверять и звуковое сопровождение нотификации.
Изображения в push-уведомлениях: Push-уведомление может содержать изображение, при отправке пуша – клиент получает ссылку на изображение и перед показом загружает его, далее происходит процесс обогащения пуша картинкой – она устанавливается. Уведомление отображается после загрузки картинки. Если push-уведомление содержит картинку, необходимо проверить, что она отображается.
Локальные push-уведомления: Локальные уведомления планируются самим приложением и служат для своевременного и актуального информирования пользователей, пока приложение не работает на переднем плане. Чтобы уведомление отобразилось, его необходимо запланировать самому пользователю. В таких случаях проверяем кейсы, связанные с таймингом отправки сообщения.
Проблемы на серверной стороне: В другие приложения приходят push-уведомления, но не приходит на наше, хотя push-токен отправлен на сервер. Стоит проверить корректность отправки push на другие аккаунты сервиса и другие устройства. При отсутствии push-уведомлений сообщите команде серверной разработки.
Источники:
Большинство багов обнаруживается на покрытии около 30% девайсов - разрешение, мощность, версия ос+нижняя граница для данной аппы. Варианты: физическая ферма устройств, эмулятор и симулятор (BrowserStack (облачный), родной в Android Studio, BlueStack, Genymotion и т.п.). Вообще физический устройств желательно иметь хотя бы штук 6 - два отличающихся айфона, по планшету на iOS и Android, 2 разных андроида. Хуавей сейчас тестится отдельно из-за гугл сервисов.
Доп. материал:
Связу́ющее програ́ммное обеспе́чение (англ. middleware; также переводится как промежу́точное программное обеспечение, программное обеспечение среднего слоя, подпрогра́ммное обеспечение, межплатфо́рменное программное обеспечение) — широко используемый термин, означающий слой или комплекс технологического программного обеспечения для обеспечения взаимодействия между различными приложениями, системами, компонентами. (с) Вики. В данном разделе нас интересует применение в мобильной разработке.
Особенностью заказной разработки мобильных приложений является то, что основной сервер с API обычно предоставляет заказчик. Ниже список, с чем в этом случае придется иметь дело мобильным разработчикам:
И добавим сюда понимание, что со всем этим придется бороться сразу на двух платформах, которые хоть и являются мобильными, часто используют разные архитектурные подходы и, как следствие, разные сроки старта и готовности этапов. Все это приводит к увеличению сроков разработки и, соответственно, стоимости разработки.
Для минимизации всех этих проблем предлагается использовать промежуточный сервер — шину данных.
Middleware - чаще всего простой быстро настраиваемый сервер, не хранящий каких-либо данных, кроме логов. Он позволяет использовать для общения мобильных приложений с собой простой REST API, строго подогнанный под логику экранов, а сам уже обращается к целевому API необходимым образом.
Бонусом мы имеем возможность разрабатывать приложения со своими наработками по авторизации, обработкам ошибок и прочим мелочам, протестированными и проверенными.
Плюсы такого подхода:
Все это позволяет снизить сроки и стоимость, напрямую и косвенно, за счет снижения рисков простоя, сложности реализации серверной части и тестирования. Шикарный бонус разработчику — возможность предложить более низкую цену и выиграть конкурс, а заказчику - сэкономить и уменьшить сроки внедрения МП.
Источник: Middleware: необходимость в мире разработки мобильных приложений
В Google Play или App Store доступны различные инструменты,, из которых можно установить приложения, такие как CPU Monitor, Usemon, CPU Stats, CPU-Z и т. д. Это расширенный инструмент, который записывает информацию о процессах, запущенных на вашем устройстве. Не все показатели могут быть доступны, это зависит от конкретного устройства. Также в инструментах разработчика доступны инструменты профилирования. Другой вариант - профилировщик в IDE (Android Studio).
Специфика работы с платформой Apple
Топ-8 причин для реджектов от Apple (в Google Play примерно также):
Специфика работы с платформой Google Play Developer:
Соблюдайте правила сторов
В Apple и Google сидят весьма смышленые ребята, основная задача которых не допустить того, чтобы приложения противоречили их политикам:
Источники:
Доп. материал:
https://developer.android.com/studio/command-line/adb.html
https://habr.com/ru/company/mobileup/blog/336992/
https://software-testing.ru/library/testing/mobile-testing/2837-mobile-deep-links
https://telegra.ph/Testirovanie-sohranennyh-poiskov-05-20
https://developer.apple.com/apple-pay/sandbox-testing/
для андроид приложений тестовые покупки доступны как на девелоп окружениях, так и на проде
Дмитрий Макаренко — Тестирование платежей в Android-приложении
Некоторая база в одной статье: Сети для начинающего IT-специалиста. Обязательная база
https://www.softwaretestinghelp.com/computer-networking-basics/
При взаимодействии клиента и сервера инициатором диалога с сервером, как правило, является клиент, сервер сам не инициирует совместную работу.
Технология клиент-сервер - шаблон проектирования, основа для создания веб-приложений, взаимодействие, при котором одна программа (клиент) запрашивает услугу (выполнение какой либо совокупности действий), а другая программа (сервер) ее выполняет.
Двухзвенная архитектура клиент-сервер:
Многоуровневая архитектура «клиент-сервер»:
Разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.
Доп. материал:
Модель OSI | ||||
Уровень (layer) | Тип данных (PDU) | Функции | Примеры | |
Host | 7. Прикладной (application) | Данные | Доступ к сетевым службам | HTTP, FTP, POP3, WebSocket |
6. Представления (presentation) | Представление и шифрование данных | ASCII, EBCDIC | ||
5. Сеансовый (session) | Управление сеансом связи | RPC, PAP, L2TP | ||
4. Транспортный (transport) | Сегменты (segment) /Дейтаграммы (datagram) | Прямая связь между конечными пунктами и надежность | TCP, UDP, SCTP, PORTS | |
Media | 3. Сетевой (network) | Пакеты (packet) | Определение маршрута и логическая адресация | IPv4, IPv6, IPsec, AppleTalk |
2. Канальный (data link) | Биты (bit)/ | Физическая адресация | PPP, IEEE 802.22, Ethernet, DSL, ARP, сетевая карта. | |
1. Физический (physical) | Биты (bit) | Работа со средой передачи, сигналами и двоичными данными | USB, кабель («витая пара», коаксиальный, оптоволоконный), радиоканал | |
Вместо OSI в реальности актуальнее знать TCP/IP. Тестировщики и разработчики почти всегда работают на прикладном уровне. Ниже может быть только тестирование VoIP и т.п.
Доп. материал:
Модель OSI - 7 уровней за 7 минут
HTTP — широко распространенный протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам), сейчас же для любых данных.
Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное ПО обрабатывает данный запрос, формирует ответ и передает его обратно клиенту.
То есть этот протокол не только устанавливает правила обмена информацией, но и служит транспортом для передачи данных — с его помощью браузер загружает содержимое сайта на ваш компьютер или смартфон.
У HTTP есть один недостаток: данные передаются в открытом виде и никак не защищены. На пути из точки А в точку Б информация в интернете проходит через десятки промежуточных узлов, и, если хоть один из них находится под контролем злоумышленника, данные могут перехватить. То же самое может произойти, когда вы пользуетесь незащищенной сетью Wi-Fi, например, в кафе. Для установки безопасного соединения используется протокол HTTPS с поддержкой шифрования.
Защиту данных в HTTPS обеспечивает криптографический протокол SSL/TLS, который шифрует передаваемую информацию. По сути этот протокол является оберткой для HTTP. Он обеспечивает шифрование данных и делает их недоступными для просмотра посторонними. Протокол SSL/TLS хорош тем, что позволяет двум незнакомым между собой участникам сети установить защищенное соединение через незащищенный канал. При установке безопасного соединения по HTTPS ваш компьютер и сервер сначала выбирают общий секретный ключ, а затем обмениваются информацией, шифруя ее с помощью этого ключа. Общий секретный ключ генерируется заново для каждого сеанса связи. Его нельзя перехватить и практически невозможно подобрать — обычно это число длиной более 100 знаков. Этот одноразовый секретный ключ и используется для шифрования всего общения браузера и сервера. Казалось бы, идеальная система, гарантирующая абсолютную безопасность соединения. Однако для полной надежности ей кое-чего не хватает: гарантии того, что ваш собеседник именно тот, за кого себя выдает. Для этой гарантии существует сертификат.
Вам как пользователю сертификат не нужен, но любой сервер (сайт), который хочет установить безопасное соединение с вами, должен его иметь. Сертификат подтверждает две вещи: 1) Лицо, которому он выдан, действительно существует и 2) Оно управляет сервером, который указан в сертификате. Выдачей сертификатов занимаются центры сертификации — что-то вроде паспортных столов. Как и в паспорте, в сертификате содержатся данные о его владельце, в том числе имя (или название организации), а также подпись, удостоверяющая подлинность сертификата. Проверка подлинности сертификата — первое, что делает браузер при установке безопасного HTTPS-соединения. Обмен данными начинается только в том случае, если проверка прошла успешно.
HTTP/2 стал первым бинарным протоколом. Если сравнивать его с прошлой версией протокола, то здесь разработчики поменяли методы распределения данных на фрагменты и их отправку от сервера к пользователю и наоборот. Новая версия протокола позволяет серверам доставлять информацию, которую клиент пока что не запросил. Это было внедрено с той целью, чтобы сервер сразу же отправлял браузеру для отображения документов дополнительные файлы и избавлял его от необходимости анализировать страницу и самостоятельно запрашивать недостающие файлы.
Еще одно отличие http 2.0 от версии 1.1 – мультиплексирование запросов и ответов для решения проблемы блокировки начала строки, присущей HTTP 1.1. Еще в новом протоколе можно сжимать HTTP заголовки и вводить приоритеты для запросов.
Доп. материал:
Компоненты HTTP
HTTP определяет следующую структуру запроса (request):
HTTP определяет следующую структуру ответного сообщения (response):
Доп. материал:
Методы HTTP-запроса
Метод, используемый в HTTP-запросе, указывает, какое действие вы хотите выполнить с этим запросом. Раньше хватало только GET, т.к. считалось, что вы можете хотеть от сервера только получить ответ. Но сейчас вам может понадобиться отредактировать профиль, удалить пост в соц. сети и т.п. Тогда для удобства были созданы различные методы. Вот основные:
Абсолютно любой веб-сервер должен работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501, если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405. Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.
Метод OPTIONS
Данный метод используется для выяснения поддерживаемых веб-сервером возможностей или параметров соединения с конкретным ресурсом. Сервер включает в ответный запрос заголовок Allow, со списком поддерживаемых методов и возможно информацию о поддерживаемых расширениях. Тело запроса клиента, содержит информацию об интересующих его данных, но на данном этапе формат тела и порядок работы с ним, не определен, пока, сервер должен его игнорировать. С ответным запросом сервера, происходит аналогичная ситуация.
Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ - "*", то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.
Метод GET
Метод GET, применяется для запроса конкретного ресурса. Так-же с помощью GET, может быть инициирован некий процесс, при этом, в тело ответа, включается информация о ходе выполнения инициированного запросом действия.
Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа "?". Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1¶m2=val2 HTTP/1.1.
Как установлено в стандарте HTTP, запросы методом GET, являются идемпотентными, то есть, повторная отправка одного и того-же запроса, методом GET, должна приводить к одному и тому-же результату, в случае, если сам ресурс, в промежутках между запросами, изменен не был, что позволяет кэшировать результаты, выдаваемые на запрос методом GET.
Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.
Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.
Метод HEAD
Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.
Заголовки ответа могут быть закэшированы, при несоответствии метаданных и информации в кэше, копия ресурса помечается как устаревшая.
Метод POST
Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method="POST", для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку "Отправить" и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.
В отличии от GET, метод POST, не является идемпотентным, то есть неоднократное повторение запроса POST, может выдавать разные результаты. В нашем случае, будет появляться новая копия комментария при каждом запросе.
Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.
Ответы сервера, на выполнение метода POST, не кэшируются.
Метод PUT
Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).
Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.
Ответы сервера при методе PUT не кэшируются.
Метод PATCH
Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.
Метод DELETE
Удаляет ресурс, расположенный по заданному URI.
Вообще по спецификации HTTP из всех методов сервер должен уметь понимать только GET, а остальные на усмотрение. Но при этом и не задано строго, что сервер должен делать при получении запроса. То есть гипотетически вы с помощью одного метода можете делать вообще любую операцию. Однако в этом нет никакого практического смысла. В дальнейшем было введено соглашение REST, определившее структуру построения веб-приложений, в том числе и работу с методами.
Источник: Методы HTTP
Доп. материал:
Различия методов GET и POST
Get:
запрос инфо от сервера
ограничение кол-ва символов: длина url 2048
передача неважных неконфиденц.данных (напр.язык,фильтры)
нет body
данные передаются в url
Get можно использовать как Post, например передавать параметры в строке (?параметр1&параметр2&параметр3..)
Но принято использовать конкретные методы запроса под конкретные задачи
Post:
добавление инфо на сервере
ограничение кол-ва символов (разработчик ставит ограничение, так как можно все поломать, в некоторых случаях), ограничено только срывом соединения клиент-сервер
можно передавать конфиденец.данные
есть body
данные передаются в body
Основное состоит в способе передачи данных веб-формы обрабатывающему скрипту, а именно:
Оба метода успешно передают необходимую информацию из веб-формы скрипту, поэтому при выборе того или иного метода, который будет наиболее подходить сайту, нужно учитывать следующие факторы:
Коды ответов/состояния сервера (HTTP status codes)
Несколько из них могут спросить чуть конкретнее, чем просто название, обычно на Ваш же выбор.
Иногда на собеседовании можно услышать вопрос: «Что дают эти коды ответа и что с ними можно делать?». На него настолько обширный ответ, что в рамках данной статьи это было бы не уместно, но конкретно для тестировщика чаще всего это просто удобное понимание, как именно отреагировал сервер на web или API запрос.
Почему ошибка 404 относится к 4** - клиентской, если по идее должна быть 5**?
Хотя интуитивно можно подумать, что данная ошибка должна относиться к ошибкам со стороны сервера, 404 по задумке является клиентской ошибкой, то есть подразумевается, что клиент (Вы) должен был знать, что URL страницы был перемещен или удален и Вы пытаетесь открыть несуществующую страницу.
На какой метод не может вернуться ошибка 501?
The HTTP 501 Not Implemented серверный код ответа на ошибку указывает, что метод запроса не поддерживается сервером и не может быть обработан. Единственными методами, которые необходимы серверам для поддержки (и, следовательно, не должны возвращать этот код), являются GET и HEAD.
TCP/IP — сетевая модель передачи данных, представленных в цифровом виде. Модель описывает способ передачи данных от источника информации к получателю. В модели предполагается прохождение информации через четыре уровня, каждый из которых описывается правилом (протоколом передачи). Наборы правил, решающих задачу по передаче данных, составляют стек протоколов передачи данных, на которых базируется Интернет.
Набор интернет-протоколов — это концептуальная модель и набор коммуникационных протоколов, используемых в Интернете и подобных компьютерных сетях. Он широко известен как TCP/IP, поскольку базовые протоколы в пакете — это протокол управления передачей (TCP) и интернет-протокол (IP).
Набор интернет-протоколов обеспечивает сквозную передачу данных, определяющую, как данные должны пакетироваться, обрабатываться, передаваться, маршрутизироваться и приниматься. Эта функциональность организована в четыре слоя абстракции, которые классифицируют все связанные протоколы в соответствии с объемом задействованных сетей.
От самого низкого до самого высокого уровня:
Доп. материал:
Смысл в том, что сайт, написанный на любом языке, поддерживающем HTTP запросы, не посылает на сервер никаких PHP/C/Python команд, а общается ним с помощью запросов, описанных в API.
Адрес, на который посылаются сообщения называется Endpoint. Обычно это URL (например, название сайта) и порт. Если я хочу создать веб сервис на порту 8080, Endpoint будет выглядеть так: http://vladislaveremeev.ru:8080
Если моему Web сервису нужно будет отвечать на различные сообщения я создам сразу несколько URL (interfaces) по которым к сервису можно будет обратиться. Например:
Как видите у моих эндпойнтов (Endpoints) различные окончания. Такое окончание в Endpoint называются Resource, а начало Base URL.
Такое определение Endpoint и Resource используется, например, в SOAP UI для RESTful интерфейсов
https://vladislaveremeev.ru:8080 - это Base URL
/resource1/status - это Resource
Endpoint = Base URL + Resource
Понятие Endpoint может использоваться в более широком смысле. Можно сказать, что какой-то определенный роутер или компьютер является Endpoint. Обычно это понятно из контекста.
Также следует обратить внимание на то, что понятие Endpoint выходит за рамки RESTful и может использовать как в SOAP так и в других протоколах.
Термин Resource также связан с RESTful, но в более широком смысле может означать что-то другое.
Итак, простейший запрос состоит из метода и Endpoint
Request = Method + Endpoint
Ресурс — это ключевая абстракция, на которой концентрируется протокол HTTP. Ресурс — это все, что вы хотите показать внешнему миру через ваше приложение. Например, если мы пишем приложение для управления задачами, экземпляры ресурсов будут следующие:
Когда вы разрабатываете RESTful сервисы, вы должны сосредоточить свое внимание на ресурсах приложения. Способ, которым мы идентифицируем ресурс для предоставления, состоит в том, чтобы назначить ему URI — универсальный идентификатор ресурса. Например:
Расшифруем аббревиатуры:
Рассмотрим примеры:
URI содержит в себе следующие части:
Общий синтаксис URI выглядит так:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
Теперь, когда мы знаем, что такое URI, URL тоже должен быть достаточно понятным. Всегда помните - URI может содержать URL, но URL указывает только адрес ресурса.
URL содержит следующую информацию:
Синтаксис:
[protocol]://www.[domain_name]:[port 80]/[path or exaction resource location]?[query]#[fragment]
Источник: url и uri - в чем различие?
Web Service - программная система, предназначенная поддерживать взаимодействие между интераперабельными устройствами через сеть. Веб сервис обладает интерфейсом, описанным в WSDL формате. Другие системы, взаимодействуют с веб сервисом через SOAP-сообщения, которые обычно передаются с помощью HTTP с XML сериализацией в связке с другими веб-стандартами.
Доп. материал:
Отличие сервиса от сервера
В контексте архитектуры программного обеспечения, сервис-ориентированности и сервис-ориентированной архитектуры термин «сервис» относится к программным функциям или набору программных функций (таких как получение указанной информации или выполнение набора операций) или «механизм, обеспечивающий доступ к одной или нескольким возможностям, где доступ предоставляется с использованием предписанного интерфейса и осуществляется в соответствии с ограничениями и политиками, указанными в описании службы».
В вычислительной технике сервер - это часть компьютерного оборудования или программного обеспечения (компьютерная программа), которая обеспечивает функциональные возможности для других программ или устройств, называемых «клиентами». Эта архитектура называется клиент-серверной. Серверы могут предоставлять различные функции, часто называемые «сервисами», такие как совместное использование данных или ресурсов между несколькими клиентами или выполнение вычислений для клиента. Один сервер может обслуживать несколько клиентов, а один клиент может использовать несколько серверов. Клиентский процесс может работать на том же устройстве или может подключаться по сети к серверу на другом устройстве. Типичными серверами являются серверы баз данных, файловые серверы, почтовые серверы, серверы печати, веб-серверы, игровые серверы и серверы приложений.
Отличие сервиса от веб-сайта
https://habr.com/ru/post/498996/
SOAP и REST нельзя сравнивать напрямую, поскольку первый - это протокол (или, по крайней мере, пытается им быть), а второй - архитектурный стиль.
Основное различие между SOAP и REST заключается в степени связи между реализациями клиента и сервера. Клиент SOAP работает как пользовательское настольное приложение, тесно связанное с сервером. Между клиентом и сервером существует жесткое соглашение, и ожидается, что все сломается, если какая-либо из сторон что-то изменит. Вам нужно постоянное обновление после любого изменения, но легче определить, выполняется ли контракт.
REST-клиент больше похож на браузер. Это универсальный клиент, который знает, как использовать протокол и стандартизированные методы, и приложение должно соответствовать этому. Вы не нарушаете стандарты протокола, создавая дополнительные методы, вы используете стандартные методы и создаете с ними действия для своего типа медиа. Если все сделано правильно, связности будет меньше, и с изменениями можно справиться более изящно.
То есть SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
Как понять используется rest или soap? Одного факта, что запросы в XML не достаточно, ведь в REST не всегда используется JSON. В SOAP свой XML и если есть последовательность специфичных нод (<soap:Envelope ... <soap:Header>), то почти наверняка это SOAP. В дополнение к этому SOAP всегда использует метод POST.
Доп. материал:
https://habr.com/ru/company/otus/blog/545688/
JSON (JavaScript Object Notation - обозначение объектов JavaScript) - текстовый формат обмена данными, основанный на JavaScript (но он не зависит от языка).
XML (eXtensible Markup Language — расширяемый язык разметки) - это язык разметки. Является выбором по умолчанию для обмена данными, остается легко читаемым, даже при больших массивах информации.
JSON благодаря популярности технологии API REST, получил импульс развития в программировании API и веб-сервисов. Это текстовый, легкий и простой в разборе формат данных, не требующий дополнительного кода для анализа. Таким образом, JSON помогает ускорить обмен данными и для веб-сервисов, которые должны просто возвращать много данных и отображать их.
Пример JSON:
{
“title”:”bananas”,
“count”:”1000”,
“description”:[“500 green”, ”500 yellow”]
}
В python аналогичная структура данных – словари. То есть это просто набор ключ: значение. При этом ключ должен быть уникальным, значений может быть любое количество. Допускается вложенность (значением может быть другой json или список).
Пример XML:
<?xml version="1.0" encoding="UTF-8"?>
<companies>
<company>
<company-id>12345</company-id>
<name lang="ru">Абракадабра</name>
<country lang="ru">Россия</country>
<phone>
<number>+7 (999) 999-99-99</number>
<ext>777</ext>
<info>Приемная</info>
<type>phone</type>
</phone>
</company>
</companies>
Как видно, XML похож на HTML, однако здесь теги не предопределены.
Если на собеседовании по какой-то причине захотят углубленно проверить эту тему, то могут спросить про разницу между well-formed и valid XML, развить в валидацию и XSD, через признаки Well-formed документа можно выйти на вложенность, а дальше на префиксы и namespace.
Доп. материал:
Источник: Веб-технологии для разработчиков - HTTP - Коды ответа HTTP - 501 Not Implemented
Доп. материал:
TCP против UDP или будущее сетевых протоколов
https://www.softwaretestingmaterial.com/website-cookie-testing/
Файл cookie HTTP (файл cookie Интернета, файл cookie браузера) представляет собой небольшой фрагмент данных (часть http заголовка), который веб-сервер хранит в текстовом файле на жестком диске пользователя (клиента). Эта часть информации затем отправляется обратно на сервер каждый раз, когда браузер запрашивает страницу с сервера. Обычно cookie-файлы содержат персонализированные пользовательские данные или информацию, которые используются для определения того, поступили ли два запроса от одного и того же браузера - например, для входа пользователя в систему или для связи между различными веб-страницами. Он запоминает информацию stateful для stateless протокола HTTP.
Куки в основном используются для трех целей:
Куки состоят в основном из трех вещей:
Максимальный размер кук = 4 килобайт (4096 байт), в некоторых источниках 4093 байт
Виды кук:
Примеры Test case для Cookie testing:
Доп. материал:
Почти всем настольным и мобильным приложениям нужно где-то хранить пользовательские данные. Но как быть веб-сайтам? В прошлом, мы использовали для этой цели файлы cookie, но у них есть серьезные ограничения. HTML5 предоставляет более подходящие инструменты для решения этой проблемы. Первый инструмент – это IndexedDB, который является излишним, говоря о замене cookie, а второй – Web Storage, являющееся комбинацией двух очень простых интерфейсов API.
Интернет-хранилище или DOM-хранилище — это программные методы и протоколы веб-приложения, используемые для хранения данных в веб-браузере. Интернет-хранилище представляет собой постоянное хранилище данных, похожее на куки, но со значительно расширенной емкостью и без хранения информации в заголовке запроса HTTP. Существуют два основных типа веб-хранилища: локальное хранилище (localStorage) и сессионное хранилище (sessionStorage), ведущие себя аналогично постоянным и сессионным кукам соответственно.
Доп. материал:
Статические сайты состоят из неизменяемых страниц. Это значит, что сайт имеет один и тот же внешний вид, а также одно и то же наполнение для всех посетителей. При запросе такого сайта в браузере сервер сразу предоставляет готовый HTML-документ в исходном виде, в котором он и был создан. Кроме HTML, в коде таких страниц используется разве что CSS и JavaScript, что обеспечивает их легкость и быструю загрузку.
Чаще всего статическими бывают сайты с минимальным количеством страниц или с контентом, который не нужно регулярно обновлять, а именно сайты-визитки, каталоги продукции, справочники технической документации. Однако с помощью сторонних инструментов существует возможность добавить на такие страницы отдельные динамические элементы (комментарии, личный кабинет для пользователей, поиск).
Динамические сайты, в свою очередь, имеют изменяемые страницы, адаптирующиеся под конкретного пользователя. Такие страницы не размещены на сервере в готовом виде, а собираются заново по каждому новому запросу. Сначала сервер находит нужный документ и отправляет его интерпретатору, который выполняет код из HTML-документа и сверяется с файлами и базой данных. После этого документ возвращается на сервер и затем отображается в браузере. Для интерпретации страниц на серверной стороне используются языки программирования Java, PHP, ASP и другие.
Самыми яркими примерами динамических сайтов являются интернет-магазины, социальные сети и т.п.
Источники:
stateful — модель, при которой объект содержит информацию о своем состоянии, все методы работают в контексте его состояния
stateless не предоставляют эту информацию. Все методы объекта работают вне какого-либо контекста или локального состояния объекта, которого в этом случае просто нет. Не делается предположений о состоянии сессии, все изменения атомарны, нет каких-то сессионных переменных на сервере, помнящих результат предыдущего запроса. Они каждый раз дают один и тот же неизменный ответ на один и тот же запрос, функцию или вызов метода. HTTP не имеет состояния в необработанном виде - если вы выполняете GET для определенного URL, вы получаете (теоретически) один и тот же ответ каждый раз.
Промежуточные команды:
Доп. материал:
Приложения и сайты в разных браузерах могут вести себя по-разному. Это связано с тем, что любой из браузеров имеет собственные движки, надстройки, плагины, а также различия в десктопной и мобильной версиях. Кроссбраузерное тестирование призвано сгладить эти различия, сделав разработку более или менее универсальной.
Почему возникают кросс-браузерные ошибки:
Доп. материал:
https://www.mindfulqa.com/cross-browser-testing/
Responsive Design (RWD) — отзывчивый дизайн — проектирование сайта с определенными значениями свойств, например, гибкая сетка макета, которые позволяют одному макету работать на разных устройствах;
Помимо своей изменяющейся структуры, у респонсив дизайна есть несколько других преимуществ:
1. Одинаковый внешний вид ресурса в разных браузерах и на различных платформах
2. Наличие у сайта одинакового URL, что способствует SEO-оптимизации
3. Разработчикам необходимо обслуживать лишь один сайт, что позволяет сократить время, затрачиваемое на дизайн и контент
И хотя положительные стороны респонсивного дизайна очевидны, у этого метода существует ряд недостатков. Самым большим из них является скорость загрузки, которая значительно снижается из-за высокого разрешения изображений и других визуальных элементов, необходимых для оформления внешнего вида ресурса.
Adaptive Design (AWD) — адаптивный дизайн, или динамический показ — проектирование сайта с условиями, которые изменяются в зависимости от устройства, базируясь на нескольких макетах фиксированной ширины.
Для создания отзывчивых макетов используются медиазапросы и относительные размеры элементов сетки, заданные с помощью %. В адаптивном дизайне серверные скрипты сначала определяют тип устройства, с помощью которого пользователь пытается получить доступ к сайту (настольный ПК, телефон или планшет), затем загружает именно ту версию страницы, которая наиболее оптимизирована для него. Для элементов сетки задаются фиксированные в пикселях (px) размеры.
Поэтому основное отличие между этими приемами — отзывчивый дизайн — один макет для всех устройств, адаптивный дизайн — один макет для каждого вида устройства. Иными словами, сервер берет на себя всю «тяжелую» работу, вместо того, чтобы заставлять сайт оптимизировать самого себя. Среди достоинств адаптивного дизайна можно выделить следующие:
Привлекательность этого метода омрачается тем, что создать адаптивный сайт не так-то просто. Из-за адаптации дизайна к различным устройствам, время, затрачиваемое на разработку, значительно увеличивается. Более того, если вам потребуется сделать какие-либо доработки на сайте, придется вносить изменения во все его версии.
Когда вы отправляете HTTP-запрос, он содержит в себе заголовки (headers) с различной информацией. Одним из них является User-Agent. Он сообщает: браузер, его версию и язык, движок браузера, версию движка, операционную систему. Данные могут быть написаны как угодно, однако примерный формат таков:
Браузер/Версия (Платформа; Шифрование; Система, Язык[; Что-нибудь еще]) [Дополнения].
Как еще можно определить, если не из хедеров? Определить версию и тип браузера можно при помощи JavaScript.
Очевидно, смотря что мы тестируем. В основном это заголовки, касающиеся авторизации, кук, кэша и юзер-агент, хотя для того же security тестера они будут иные.
Доп. материал:
Аутентификация | Авторизация |
Процедура проверки подлинности субъекта | Процедура присвоения и проверки прав на совершение определенных действий субъектом |
Зависит от предоставляемой пользователем информации | Не зависит от действий клиента |
Запускается один раз для текущей сессии | Происходит при попытке совершения любых действий пользователем |
Как работает авторизация/аутентификация? Как сайт понимает, что ты залогинен?
Идентификация — процедура, в результате выполнения которой для субъекта идентификации выявляется его идентификатор, однозначно определяющий этого субъекта в информационной системе.
Аутентификация — процедура проверки подлинности, например проверка подлинности пользователя путем сравнения введенного им пароля с паролем, сохраненным в базе данных.
Авторизация — предоставление определенному лицу или группе лиц прав на выполнение определенных действий.
https://www.kaspersky.ru/blog/identification-authentication-authorization-difference/29123/
Классический вариант – регистрация по логину/почте и паролю. При входе и введении правильных данных, если данные совпадают с таковыми в базе, вы получаете доступ на сайт.
1. Т.к. протокол HTTP не отслеживает состояния, нельзя достоверно знать, что человек, залогинившийся до этого по почте и паролю остается тем же человеком. И тогда изобрели аутентификацию на основе сессий/кук, на основе которых реализовано отслеживание состояний (stateful), то есть аутентификационная запись или сессия хранятся как на сервере, так и на клиенте. Сервер отслеживает открытые сессии в базе данных или в оперативной памяти, в свою очередь на фронтенде создаются cookies, в которых хранится идентификатор сессии. Процедура аутентификации на основе сессий:
У этого метода есть и недостатки:
2. Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений (SPA), веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.
При аутентификации на основе токенов состояния не отслеживаются (stateless). Мы не будем хранить информацию о пользователе на сервере или в сессии и даже не будем хранить JWT, использованные для клиентов.
Процедура аутентификации на основе токенов:
У метода есть ряд преимуществ:
Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передает затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, еще одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.
Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.
Примечание: в целях безопасности в некоторых случаях в дополнение к токену применяется сравнение user agent и подобного. В случае различия вас разлогинит. Так же, например, в банковских системах нельзя одновременно залогиниться в одну учетную запись с нескольких устройств одновременно.
3. Беспарольная аутентификация
Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»
В наши головы внедрено убеждение, что пароли — абсолютный источник защиты наших аккаунтов. Но если изучить вопрос глубже, то выяснится, что беспарольная аутентификация может быть не просто безопасной, но и безопаснее традиционного входа по имени и паролю. Возможно, вы даже слышали мнение, что пароли устарели.
Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:
Вместо ввода почты/имени и пароля пользователи вводят только свою почту. Ваше приложение отправляет на этот адрес одноразовую ссылку, пользователь по ней кликает и автоматически входит на ваш сайт / в приложение. При беспарольной аутентификации приложение считает, что в ваш ящик пришло письмо со ссылкой, если вы написали свой, а не чужой адрес.
Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придется объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.
И еще один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.
Medium предоставляет доступ к своему сайту только по почте. Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.
Что может пойти не так?
Если кто-то получит доступ к пользовательским почтам, он получит и доступ к приложениям и сайтам. Но это не ваша головная боль — беспокоиться о безопасности почтовых аккаунтов пользователей. Кроме того, если кто-то получит доступ к чужой почте, то сможет перехватить аккаунты в приложениях с беспарольной аутентификацией, воспользовавшись функцией восстановления пароля. Но мы ничего не можем поделать с почтой наших пользователей. Пойдем дальше.
В чем преимущества?
Как часто вы пользуетесь ссылкой «забыли пароль» для сброса пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей». Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.
Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.
Сегодня беспарольная аутентификация быстро набирает популярность.
4. Единая точка входа (Single Sign On, SSO)
Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например, Gmail, а потом идешь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автоматически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но все же раздельные продукты. Как они аутентифицируют пользователя во всех продуктах после единственного входа?
Этот метод называется единой точкой входа (Single Sign On, SSO).
Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создает куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:
Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.
Выглядит очень просто, но конкретные реализации бывают очень сложными.
5. Аутентификация в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придется регистрироваться отдельно в вашем приложении.
Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.
Пользователи могут войти в ваше приложение одним кликом, если у них есть аккаунт в одной из соцсетей. Им не нужно помнить логины и пароли. Это сильно улучшает опыт использования вашего приложения. Вам не нужно волноваться о безопасности пользовательских данных и думать о проверке адресов почты — они уже проверены соцсетями. Кроме того, в соцсетях уже есть механизмы восстановления пароля.
Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth2 (некоторые используют OAuth1, например Twitter). Разберемся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмет этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).
Для реализации такого механизма вам может понадобиться зарегистрировать свое приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д. ), которые помогут упростить процедуру и избавят от излишней возни.
6. Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счет использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдет вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.
Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включен этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищенным, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.
Вместо одноразового пароля в качестве второго фактора могут использоваться отпечатки пальцев или снимок сетчатки.
При двухфакторной аутентификации пользователь должен предоставить два из трех:
То, что вы знаете: пароль или PIN.
То, что у вас есть: физическое устройство (смартфон) или приложение, генерирующее одноразовые пароли.
Часть вас: биологически уникальное свойство вроде ваших отпечатков пальцев, голоса или снимка сетчатки.
Большинство хакеров охотятся за паролями и PIN-кодами. Гораздо труднее получить доступ к генератору токенов или биологическим свойствам, поэтому сегодня двухфакторка обеспечивает высокую безопасность аккаунтов.
И все же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.
Доп. материал:
Кэш — это временное хранилище для данных (перечень определен создателем сайта) с посещенного сайта. Во-первых, многие элементы на страницах сайта одинаковы: изображения, HTML, CSS, JavaScript и нет смысла каждый раз загружать их заново. Во-вторых, при повторном открытии той же самой страницы действует та же логика – эти элементы уже были загружены, ни к чему грузить их каждый раз по новой.
Сохранение данных веб-страниц на компьютере, вместо их повторной загрузки, помогает экономить время открытия веб-сайтов в браузере и трафик, но с другой стороны снижает срок службы SSD-накопителей, так что вы всегда можете полностью отключить кеширование в своем браузере.
Виды кеширования:
В тестировании практически во всех случаях правило – очищать кэш после каждого прохода теста (если только это не целенаправленной тестирование самого кэша или требуется наличие кэша по каким-либо причинам). Дело в том, что кэш очевидно искажает показатели performance testing, а также может быть причиной ошибочного дефект-репорта из-за устаревания и/или несогласованности актуальных и сохраненных данных. В некоторых ситуациях без очистки кеша не обойтись даже просто из-за огромного количества кешируемых данных.
https://en.wikipedia.org/wiki/Message_broker
https://habr.com/ru/post/466385/
Ajax ( Asynchronous Javascript and XML — «асинхронный JavaScript и XML») — подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате при обновлении данных веб-страница не перезагружается полностью, и веб-приложения становятся быстрее и удобнее. По-русски иногда произносится транслитом как «аякс». У аббревиатуры AJAX нет устоявшегося аналога на кириллице.
В классической модели веб-приложения:
При использовании AJAX:
Типичный сценарий использования предполагает отправку на некий сервер GET запроса и отображение полученного ответа. При этом происходит много всего: резолв домена в DNS -> получение целевого IP -> TCP/IP финты -> на запрос отдается запрашиваемая страница. Отображение страницы тоже не такой простой процесс:
Модуль отображения выполняет синтаксический анализ полученного HTML-документа и переводит теги в узлы DOM(DOM – объектная модель документа (Document Object Model) – служит для представления HTML-документа и интерфейса элементов HTML таким внешним объектам, как код JavaScript.) в дереве содержания. Информация о стилях извлекается как из внешних CSS-файлов, так и из элементов style. Эта информация и инструкции по отображению в HTML-файле используются для создания еще одного дерева – дерева отображения.
Оно содержит прямоугольники с визуальными атрибутами, такими как цвет и размер. Прямоугольники располагаются в том порядке, в каком они должны быть выведены на экран.
После создания дерева отображения начинается компоновка элементов, в ходе которой каждому узлу присваиваются координаты точки на экране, где он должен появиться. Затем выполняется отрисовка, при которой узлы дерева отображения последовательно отрисовываются с помощью исполнительной части пользовательского интерфейса.
Доп. материал:
Почему связь «сотовая»? Если посмотреть сверху на схему сети базовых станций, то их пересекающиеся краями круги покрытия похожи на пчелиные соты.
Сотовая связь потому и называется сотовой, что в основе любой сети — ячейки (соты), каждая сота представляет собой участок территории, который покрывает (обслуживает) базовая станция. Форма и размеры сот зависят от множества факторов, в том числе от мощности излучения базовой станции, стандарта, рабочих частот, направления антенн и т.п. Соты обязательно перекрывают друг друга, это необходимо для того, чтобы мобильное устройство (терминал) не теряло связь при перемещении из одной соты в другую. Особенно это важно для владельца сотового телефона, который разговаривает во время движения.
В условиях городской застройки невозможно разбить карту города на квадратики и поставить базовые станции через равные расстояния, чтобы добиться качественного покрытия. Начинают играть роль этажность застройки, препятствия в виде памятников, возможность установить базовые станции в том или ином месте. Не зря наши города назвали каменными джунглями, планирование в них радиосетей – это та еще задачка. Поэтому все операторы стараются резервировать дополнительные мощности в крупных городах, создавать перекрывающиеся зоны для базовых станций. И этому есть и другая причина.
Для эффективной работы сети одного покрытия мало, базовые станции должны обслуживать одновременно много пользователей. А в городах — очень много одновременно разговаривающих и пользующихся мобильным интернетом. Полосы частот, на которых передаются голос и данные, — ограниченный и крайне ценный ресурс, за их лицензирование операторы во всем мире платят государству большие деньги.
Когда вы набираете номер и начинаете звонить, ну, или вам кто-нибудь звонит, то ваш мобильный телефон по радиоканалу связывается с одной из антенн ближайшей базовой станции. От антенны сигнал по кабелю передается непосредственно в управляющий блок станции. Базовая станция должна выделить вам свободный голосовой канал. Вместе они и образуют базовую станцию [антенны и управляющий блок]. Несколько базовых станций, чьи антенны обслуживают отдельную территорию, например, район города или небольшой населенный пункт, подсоединены к специальному блоку – контроллеру. К одному контроллеру обычно подключается до 15 базовых станций. В свою очередь, контроллеры, которых также может быть несколько, кабелями подключены к «мозговому центру» – коммутатору. Коммутатор обеспечивает выход и вход сигналов на городские телефонные линии, на других операторов сотовой связи, а также операторов междугородней и международной связи.
В небольших сетях используется только один коммутатор, в более крупных, обслуживающих сразу более миллиона абонентов, могут использоваться два, три и более коммутаторов, объединенных между собой опять-таки проводами.
Когда человек передвигается по улице пешком или идет на автомобиле, поезде и т. д. и при этом еще и разговаривает по телефону, важно обеспечить непрерывность связи. Связисты процесс эстафетной передачи обслуживания в мобильных сетях называют термином «handover». Необходимо вовремя переключать телефон абонента из одной базовой станции на другую, от одного контроллера к другому и так далее.
Если бы базовые станции были напрямую подключены к коммутатору, то всеми этими переключениями пришлось бы управлять коммутатору. А ему «бедному» и так есть, чем заняться. Многоуровневая схема сети дает возможность равномерно распределить нагрузку на технические средства. Это снижает вероятность отказа оборудования и, как следствие, потери связи. Итак, достигнув коммутатора, наш звонок переводится далее – на сеть другого оператора мобильной, городской междугородной и международной связи. Конечно же, это происходит по высокоскоростным кабельным каналам связи. Звонок поступает на коммутатор другого оператора. При этом последний «знает», на какой территории [в области действия, какого контроллера] сейчас находится нужный абонент. Коммутатор передает телефонный вызов конкретному контроллеру, в котором содержится информация, в зоне действия какой базовой станции находится адресат звонка. Контроллер посылает сигнал этой единственной базовой станции, а она в свою очередь «опрашивает», то есть вызывает мобильный телефон. Точно также происходят телефонные звонки в разные города России, Европы и мира. Для связи коммутаторов различных операторов связи используются высокоскоростные оптоволоконные каналы связи. Благодаря им сотни тысяч километров телефонный сигнал преодолевает за считанные секунды или даже доли секунд.
После этого, все устройства, находящиеся во внутренней сети, будут выходить в Интернет через роутер под одним внешним IP-адресом, но в локальной сети они будут иметь разный IP.
https://www.softwaretestingmaterial.com/database-testing/
https://www.softwaretestingmaterial.com/database-testing-interview-questions/
Доп. материал:
Может и даже разного типа. Но в простых случаях делать это стоит только когда все упрется в предел производительности. Начиная с миллиардов записей у одной даже хорошо оптимизированной БД на одной hardware дисковой подсистеме уже могут начаться проблемы с performance, поэтому компания может принять решение разнести одну базу на несколько баз на разных серверах, но вместе с этим появляются вопросы к сетевому аспекту этого решения (задержки и т.п.). Помимо производительности, разделение на несколько БД может быть в угоду безопасности.
structured query language — «язык структурированных запросов» — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных.
“NoSQL” имеет абсолютно стихийное происхождение и не имеет общепризнанного определения или научного учреждения за спиной. Это название скорее характеризует вектор развития ИТ в сторону от реляционных баз данных. Расшифровывается как Not Only SQL. Базы данных NoSQL специально созданы для определенных моделей данных и обладают гибкими схемами, что позволяет разрабатывать современные приложения. Базы данных NoSQL получили широкое распространение в связи с простотой разработки, функциональностью и производительностью при любых масштабах.
Доп. материал:
Транзакция — это набор операций по работе с базой данных (БД), объединенных в одну атомарную пачку. Или, если говорить по-научному, то транзакция — упорядоченное множество операций, переводящих базу данных из одного согласованного состояния в другое. Согласованное состояние — это состояние, которое подходит под бизнес-логику системы.
Источник: Что такое транзакция
Терминология:
Нормальные формы:
Хранимые процедуры представляют собой группы связанных между собой операторов SQL, применение которых делает работу программиста более легкой и гибкой, поскольку выполнить хранимую процедуру часто оказывается гораздо проще, чем последовательность отдельных операторов SQL. Хранимые процедуры представляют собой набор команд, состоящий из одного или нескольких операторов SQL или функций и сохраняемый в базе данных в откомпилированном виде.
Три́ггер (англ. trigger) — хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации данных: добавлением INSERT, удалением DELETE строки в заданной таблице, или изменением UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики. Триггер запускается автоматически при попытке изменения данных в таблице, с которой он связан. Все производимые им модификации данных рассматриваются как выполняемые в транзакции, в которой выполнено действие, вызвавшее срабатывание триггера. Соответственно, в случае обнаружения ошибки или нарушения целостности данных может произойти откат этой транзакции.
Индекс - объект базы данных, создаваемый с целью повышения производительности поиска данных. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в произвольном порядке, и их поиск по заданному критерию путем последовательного просмотра таблицы строка за строкой может занимать много времени. Индекс формируется из значений одного или нескольких столбцов таблицы и указателей на соответствующие строки таблицы и, таким образом, позволяет искать строки, удовлетворяющие критерию поиска. Ускорение работы с использованием индексов достигается в первую очередь за счет того, что индекс имеет структуру, оптимизированную под поиск — например, сбалансированного дерева. Различные типы индексов:
Требования ACID на простом языке
http://www.plam.ru/compinet/mysql_rukovodstvo_professionala/p45.php
https://www.softwaretestinghelp.com/database-testing-process/
https://engineering.helpscout.com/testing-code-that-talks-to-the-database-7d15a5391fb9
https://towardsdatascience.com/testing-your-database-a0eee0d44115
Тестировщик проверяет стандартный формат хранимых процедур, а также проверяет правильность полей, таких как updates, joins, indexes, deletions как указано в хранимой процедуре.
В журнале аудита (audit log) вы можете увидеть срабатывание триггеров.
SHOW DATABASES;
CREATE DATABASE;
USE <database_name>;
SOURCE <path_of_.sql_file>;
DROP DATABASE <database_name>;
SHOW TABLES;
CREATE TABLE <table_name1> (
<col_name1> <col_type1>,
<col_name2> <col_type2>,
<col_name3> <col_type3>
PRIMARY KEY (<col_name1>),
FOREIGN KEY (<col_name2>) REFERENCES <table_name2>(<col_name2>)
);
INSERT INTO <table_name> (<col_name1>, <col_name2>, <col_name3>, …)
VALUES (<value1>, <value2>, <value3>, …);
При добавлении данных в каждый столбец таблицы не требуется указывать названия столбцов.
INSERT INTO <table_name>
VALUES (<value1>, <value2>, <value3>, …);
UPDATE <table_name>
SET <col_name1> = <value1>, <col_name2> = <value2>, ...
WHERE <condition>;
DELETE FROM <table_name>;
DROP TABLE <table_name>;
SELECT используется для получения данных из определенной таблицы:
SELECT <col_name1>, <col_name2>, …
FROM <table_name>;
SELECT * FROM <table_name>;
SELECT DISTINCT
SELECT DISTINCT <col_name1>, <col_name2>, …
FROM <table_name>;
WHERE
SELECT <col_name1>, <col_name2>, …
FROM <table_name>
WHERE <condition>;
сравнение текста;
сравнение численных значений;
логические операции AND (и), OR (или) и NOT (отрицание).
Пример
Попробуйте выполнить следующие команды. Обратите внимание на условия, заданные в WHERE:
SELECT * FROM course WHERE dept_name=’Comp. Sci.’;
SELECT * FROM course WHERE credits>3;
SELECT * FROM course WHERE dept_name='Comp. Sci.' AND credits>3;
SELECT <col_name1>, <col_name2>, …
FROM <table_name>
GROUP BY <col_namex>;
Пример
Выведем количество курсов для каждого факультета:
SELECT COUNT(course_id), dept_name
FROM course
GROUP BY dept_name;
SELECT <col_name1>, <col_name2>, ...
FROM <table_name>
GROUP BY <column_namex>
HAVING <condition>
Пример
Выведем список факультетов, у которых более одного курса:
SELECT COUNT(course_id), dept_name
FROM course
GROUP BY dept_name
HAVING COUNT(course_id)>1;
SELECT <col_name1>, <col_name2>, …
FROM <table_name>
ORDER BY <col_name1>, <col_name2>, … ASC (вертикальная черта) DESC;
Пример
Выведем список курсов по возрастанию и убыванию количества кредитов:
SELECT * FROM course ORDER BY credits;
SELECT * FROM course ORDER BY credits DESC;
SELECT <col_name1>, <col_name2>, …
FROM <table_name>
WHERE <col_namex> BETWEEN <value1> AND <value2>;
Пример
Выведем список инструкторов, чья зарплата больше 50 000, но меньше 100 000:
SELECT * FROM instructor
WHERE salary BETWEEN 50000 AND 100000;
Есть два свободных оператора, которые используются в LIKE:
% (ни одного, один или несколько символов);
_ (один символ).
SELECT <col_name1>, <col_name2>, …
FROM <table_name>
WHERE <col_namex> LIKE <pattern>;
Пример
Выведем список курсов, в имени которых содержится «to», и список курсов, название которых начинается с «CS-»:
SELECT * FROM course WHERE title LIKE ‘%to%’;
SELECT * FROM course WHERE course_id LIKE 'CS-___';
SELECT <col_name1>, <col_name2>, …
FROM <table_name>
WHERE <col_namen> IN (<value1>, <value2>, …);
Пример
Выведем список студентов с направлений Comp. Sci., Physics и Elec. Eng.:
SELECT * FROM student
WHERE dept_name IN (‘Comp. Sci.’, ‘Physics’, ‘Elec. Eng.’);
Создание
CREATE VIEW <view_name> AS
SELECT <col_name1>, <col_name2>, …
FROM <table_name>
WHERE <condition>;
Удаление
DROP VIEW <view_name>;
Пример
Создадим view, состоящую из курсов с 3 кредитами:
COUNT (col_name) — возвращает количество строк;
SUM (col_name) — возвращает сумму значений в данном столбце;
AVG (col_name) — возвращает среднее значение данного столбца;
MIN (col_name) — возвращает наименьшее значение данного столбца;
MAX (col_name) — возвращает наибольшее значение данного столбца.
Пример
Найдем курсы, которые преподавались осенью 2009 и весной 2010 годов:
SELECT DISTINCT course_id
FROM section
WHERE semester = ‘Fall’ AND year= 2009 AND course_id IN (
SELECT course_id
FROM section
WHERE semester = ‘Spring’ AND year= 2010
);
Доп. материал:
Как и было сказано выше, различные виды JOIN помогают объединить некие данные из нескольких таблиц каким-либо образом.
Так чем отличается INNER JOIN от LEFT JOIN? Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.
Это понимание и подобные ответы – по сути не совсем верны, т.к. все джойны – декартово произведение (cross join) с фильтрами (предикатом и, возможно, UNION). Также стоит обратить внимание на порядок таблиц при различных джойнах.
Доп. материал:
Понимание джойнов сломано. Это точно не пересечение кругов, честно
SQL на котиках: Джоины (Joins)
Вопрос номер один практически на всех собеседованиях на младшую позицию. Он хорош еще и тем, что в зависимости от уровня кандидата будет раскрыт в разной степени. Всегда в первую очередь уточняйте хотя бы какие-то минимальные требования, даже если вначале озвучивают, что требования не формализованы.
Есть еще форма посложнее (с просторов коммьюнити, автор @azshoo):
Или вот еще с просторов, реальное тестовое задание. Можно их много найти, если поискать.
Доп. материал:
Очень частый вопрос на собеседованиях. Либо вам дают конкретные примеры дефектов, для которых вы должны определить серьезность и приоритет, либо вас самих просят придумать варианты дефектов в каких-либо ситуациях. Например, дверь в магазине. Какой дефект может быть с низкой серьезностью, но высоким приоритетом? У каждой компании найдутся свои варианты вопросов, так что потренируйтесь заранее.
Следующий по популярности вопрос. Зная азы этих техник тест-дизайна, ответить довольно просто, но все равно будьте внимательнее. Потренироваться можно на просторах интернета.
Доп. материал:
Могут быть буквально на логику (тесты Войнаровского):
«Саша смотрит на Ольгу, а Ольга смотрит на Андрея. У Саши есть дети, у Андрея нет. Смотрит ли человек, у которого есть дети, на человека, у которого детей нет? Варианты ответа: «Да», «Нет», «Нельзя определить». Объясните свою точку зрения.»
На рассуждение и перебор вариантов, цель - увидеть, как думает кандидат и насколько он эрудирован:
Или на «логику»:
«Есть две изолированные друг от друга комнаты. В одной находятся 3 лампочки, в другой - три выключателя. Вы стоите в комнате с выключателями и можете перейти в комнату с лампочками лишь один раз. Необходимо определить, какая лампочка включается каким выключателем.»
К первому типу можно подготовиться, изучив самые азы мат. логики и порешав несколько примеров. Многие относятся к этому несерьезно и проваливают этот тип заданий, между тем такие задачки щелкают на олимпиадах 5-клашки.
Второй тип задач показывает эрудированность в области computer science, здесь помогут только базовые общие курсы.
Про подготовку ко третьему типу задач, если опустить дискуссии об их бесполезности, можно сказать только то, что проще их просто прочитать и запомнить решение. Подробнее изучить тему можно в популярной книге «Как сдвинуть гору Фудзи».
Доп. материал:
Мы нашли все самые крутые логические задачи
Vladislav Eremeev, [02.04.21 10:01]
[Forwarded from Pavel Panov]
На собеседовании интересньій вопрос задали.
Делюсь.
Есть некий обучающий портал с видео.
Видео можно смотреть бесплатно до некоторой величиньі.
При просмотре видео на 80% считается, что просмотрщик согласен заплатить (необходимо пометить видео как просмотренное, добавить в некий список, не суть)
Vladislav Eremeev, [02.04.21 10:01]
[Forwarded from Pavel Panov]
Необходимо накидать тестов, как проверить просмотр 80% контента.
Vladislav Eremeev, [02.04.21 10:01]
[Forwarded from Pavel Panov]
На собеседовании далиютуб, какоето видео (от фонаря), я еще открьіл ДЕв тулс
Vladislav Eremeev, [02.04.21 10:01]
[Forwarded from Pavel Panov]
подождем еще вариантов.
(но для вас - встречньій вариант - а если просмотреть 10% (20... 30...) - и начать сначала?
Спрашивали написать конкртньій тест кейс проверок. Вот прям дали ютуб и сидят ждут ответ, в zoom. Причем не ограничивают во времени в разумньіх пределах)
Маркетологи используют специальные параметры в URL, чтобы лучше отслеживать кампании. Эти параметры называются параметрами UTM (модуль отслеживания Urchin). У нас есть страница, которая принимает URL-адрес, индивидуальные параметры UTM и компилирует конечный URL-адрес, которым люди могут поделиться. Сотни людей приходят сюда каждую неделю, поэтому необходимо, чтобы этот сайт работал без проблем - компиляция URL, а также поддержка различных браузеров и устройств. Ваша задача создать «тест-кейсы» для этого сайта
Доп. материал:
Не уверен, что это еще популярно спрашивать, но на всякий случай пара примеров с просторов.
Сначала – позитивное тестирование.
Функции чашки:
- вмещать напитки,
- переносить напитки,
- возможность пить из нее,
- возможность греть напитки в микроволновке.
Проверим сначала «вмещать»:
Поставили на поверхность – стоит, не падает - все ок.
Холодной воды налили – вода внутри - все ок.
Кипятку налили - не треснула, не течет – все ок.
*сперва хотела лить только горячую (раз горячую выдержит, то холодную – само собой), но потом решила, что это будет заодно и стрессовое тестирование (испытание на перепад температур).
Теперь – «переносить»:
Есть ручка, за нее можно взяться и поднять/перенести даже полную и горячую чашку (пустую и холодную носить не станем, если предусмотрен более тяжелый тест).
Теперь – «пить из нее»:
Наклонять удается, отхлебывать – тоже. Все ок.
«Возможность греть в микроволновке»:
Если в инструкции к чашке не указана максимальная допустимая температура при подогреве в печи, наливаем воду, ставим чашку в печь и включаем на максимум
По идее, нужно ставить таймер на время, достаточное для нагрева напитка до 100 градусов. Потому что если он выкипит, а чашка перегреется, это уже не будет позитивным тестированием.
Если позитивное тестирование удачно, проведем негативное (ошибочные или нестандартные, но возможные действия с предметом):
Подвергнем ее
- механическому (об пол, ап стену),
- химическому (кротом, адриланом, уксусной кислотой),
- физическому воздействию (перегреем в микроволновке, поставим на раскаленную горелку).
Еще - «тестирование удобства пользователя»:
удобно ли ставить, не горячо ли носить, приятно ли браться за ручку и т. д.
Еще – «тестирование безопасности»:
Вот на работе у меня чашка – маленькая, и край отбитый. Поэтому ее никто не трогает, когда меня нет. А эту наверняка все таскали бы – большая, удобная, красивая… Мне не жалко, но тест безопасности она бы не прошла.
Еще – «тестирование взаимодействия»:
встает ли чашка на блюдца от других сервизов.
Задача на умение пользоваться инструментами, позволяющими подменять трафик. По обстоятельствам.
“Нужны ТЗ, макет, идеально - прототип. “А дальше считаете по самой простой эстимации по тест-кейсам. Функциональное: позитивные и негативные сценарии на поля ввода; чек-боксы, подписки, имэйлы, тултипы, хинты, кнопки, линки и футэр; Кроссбраузерное и кроссплатформенное: здесь надо уточнить, для каких браузеров и девайсов тестируете; UI/UX: сверка с элементами макета в дев тулз на разных браузерах и девайсах; Грей бокс метод: смотрим, как сторятся отправленные данные в админке/бд. Плюс полный флоу прохождения регистрации в качестве смоука. Ну а потом прикидываете количество кейсов, на каждый кейс закладываете, сколько вы на него потратите времени (по-разному, здесь вы учитываете свою скорость)+20% на риски. Плюс закладываете время для регрессии.
В общем, в этом задании вам важно задать правильные вопросы) иначе будет из оперы "не зная тз - получишь хз" (с) @DorityTM
Для оценок в общем виде существует Метод оценки по 3 точкам (Three Point Estimation)
Один из самых распространенных и простых методов. В рамках него сначала определяются оптимистичная (O = Optimistic), пессимистичная (P = Pessimistic) и реалистичная/средняя (M = Middle) оценки.
Значения P, M и O определяются экспертно (в часах, днях, $), например, в ходе обсуждения внутри проектной команды. Для этого задаются вопросы такого типа: «сколько времени займет проект, если все пойдет хорошо, не будет никаких рисков и проблем?», «каким может быть самый негативный сценарий и сколько на него потребуется времени/усилий?» и т.п.
Далее полученные значения P, M и O подставляются в формулу: (O + 4 M + P) / 6
Результат расчета дает усредненную оценку. Такая формула позволяет с одной стороны учесть возможные позитивные и негативные сценарии, а с другой – «сгладить» их влияние и получить более реальное значение оценки.
Доп. материал:
Truthful Estimations by James Bach at ThinkTest 2015 (вкратце: "начну, потестирую немного, прикину, скажу")
Автор: Еремеев Владислав
Поскольку проект open-source, каждый может внести посильный вклад в его (и всех читающих) развитие. Смело можете писать, особенно если:
Контрибьютинг горячо приветствуется, особенно если:
Также приветствуются аргументированная критика и предложения.
Любое использование материалов проекта, в т.ч. коммерческое, допускается при указании авторства/первоисточника согласно лицензии GPL-3.0 (пламенный привет компаниям, которые вырезали контакты и закинули материал в корпоративную базу знаний как свой).
Если ресурс чем-то помог, поддержите проект материально скромным донатом:
в РФ +79044121375 alfabank или баланс;
в СНГ вроде должно работать это https://boosty.to/qa_bible
Удачи в карьере!
